Method and apparatus for providing information to a network

ABSTRACT

Method and apparatus for providing information to a network are disclosed. An eNodeB (eNB) may receive pattern information relating to connection state management behavior of a wireless transmit/receive unit (WTRU). The eNB may receive this information over S1 signaling when a connection is established. The eNB may determine a time factor for connection state management, wherein the time factor may be based on the received information. The determine time factor may be used to adjust connection states of the WTRU.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.15/499,600 filed Apr. 27, 2017 which is a continuation of Ser. No.13/436,457 filed Mar. 30, 2012 and issued as U.S. Pat. No. 9,648,657 onMay 9, 2017, which claims the benefit of U.S. provisional applicationNos. 61/470,953 filed Apr. 1, 2011, 61/555,653 filed Nov. 4, 2011,61/591,389 filed Jan. 27, 2012, and 61/611,974 filed Mar. 16, 2012, thecontents of which are hereby incorporated by reference herein.

BACKGROUND

Third Generation Partnership Project (3GPP) Long Term Evolution (LTE)Release 8/9 (LTE R8/9) supports up to 100 Mbps in the downlink (DL), and50 Mbps in the uplink (UL) for a 2×2 configuration. The LTE DLtransmission scheme is based on an orthogonal frequency divisionmultiple access (OFDMA) air interface.

For flexible deployment, LTE R8/9 systems support scalable transmissionbandwidths, one of 1.4, 2.5, 5, 10, 15, or 20 MHz. In LTE, each radioframe (10 ms) comprises 10 equally sized sub-frames of 1 ms. Eachsub-frame comprises 2 equally sized timeslots of 0.5 ms each. Either 7or 6 orthogonal frequency division multiplex (OFDM) symbols exist pertimeslot depending on the length of the cyclic prefix (CP). 7 symbolsper timeslot are used with normal CP length, and 6 symbols per timeslotare used with the extended CP length. The sub-carrier spacing for theLTE is 15 kHz. An alternative reduced sub-carrier spacing mode using 7.5kHz is also possible.

A resource element (RE) corresponds to one (1) sub-carrier during one(1) OFDM symbol interval. 12 consecutive sub-carriers during a 0.5 mstimeslot constitute one (1) resource block (RB). Therefore, with 7symbols per timeslot, each RB consists of 12×7=84 REs. A DL carrier maycomprise a scalable number of RBs, ranging from 6 RBs up to 110 RBs.This corresponds to an overall scalable transmission bandwidth ofroughly 1 MHz up to 20 MHz. Normally, a set of common transmissionbandwidths is specified, e.g., 1.4, 3, 5, 10, or 20 MHz.

The basic time-domain unit for dynamic scheduling is one sub-framecomprising two consecutive timeslots, which may be referred to as aresource-block pair. Certain sub-carriers on some OFDM symbols areallocated to carry pilot signals in the time-frequency grid. A givennumber of sub-carriers at the edges of the transmission bandwidth arenot transmitted in order to comply with spectral mask requirements.

LTE-Advanced with carrier aggregation is an evolution that aims toimprove single carrier LTE R8/9/10 data rates using, among othermethods, bandwidth extensions (i.e., carrier aggregation). With carrieraggregation, a WTRU may transmit and receive simultaneously over aphysical uplink shared channel (PUSCH) and a physical downlink sharedchannel (PDSCH), respectively, on multiple serving cells. Up to foursecondary cells (SCells) may be configured in addition to a primaryserving cell (PCell). It may support flexible bandwidth assignments upto 100 MHz.

The control information for the scheduling of PDSCH and PUSCH may besent on one or more physical downlink control channels (PDCCHs). Inaddition to the LTE R8/9 scheduling using one PDCCH for a pair of UL andDL carriers, cross-carrier scheduling may be supported for a givenPDCCH, allowing the network to provide PDSCH assignments and/or PUSCHgrants for transmissions in other serving cell(s).

In LTE R8/9 and LTE Release 10 (R10) with single carrier configuration,where the network assigns a wireless transmit/receive unit (WTRU) onepair of UL and DL carriers, for any given subframe there is a singlehybrid automatic repeat request (HARQ) process active for the UL and asingle HARQ process active in the DL.

In LTE R10 with carrier aggregation configured, there is one HARQ entityfor each serving cell. There may be more than one HARQ processes activefor the UL and for the DL in any given subframe, but at most one UL andone DL HARQ process per configured serving cell.

SUMMARY

A method and apparatus for providing information to a network aredisclosed. An eNodeB (eNB) may receive pattern information relating toconnection state management behavior of a wireless transmit/receive unit(WTRU). The eNB may receive this information over S1 signaling when aconnection is established. The eNB may determine a time factor forconnection state management, wherein the time factor may be based on thereceived information. The determine time factor may be used to adjustconnection states of the WTRU.

BRIEF DESCRIPTION OF THE DRAWINGS

A more detailed understanding may be had from the following description,given by way of example in conjunction with the accompanying drawingswherein:

FIG. 1A is a system diagram of an example communications system in whichone or more disclosed embodiments may be implemented;

FIG. 1B is a system diagram of an example wireless transmit/receive unit(WTRU) that may be used within the communications system illustrated inFIG. 1A;

FIG. 1C is a system diagram of an example radio access network and anexample core network that may be used within the communications systemillustrated in FIG. 1A;

FIG. 2 shows an example bearer service architecture wherein packetfilters are used to direct packets to the relevant radio bearer;

FIG. 3 shows state transitions among RRC_IDLE, RRC_CONNECTED, andRRC_DORMANT in accordance with one embodiment;

FIG. 4 shows a diagram of example state transitions at the non-accessstratum (NAS);

FIG. 5 is a signaling diagram of an example process for sessionmanagement in accordance with one embodiment;

FIG. 6 is a signaling diagram of an example process of entering adormant mode in accordance with one embodiment;

FIG. 7 shows an example procedure for traffic detection function(TDF)-based control plane policing in accordance with one embodiment;and

FIG. 8 shows routing of the packets from the unwanted flow to aparticular radio bearer.

DETAILED DESCRIPTION

FIG. 1A is a diagram of an example communications system 100 in whichone or more disclosed embodiments may be implemented. The communicationssystem 100 may be a multiple access system that provides content, suchas voice, data, video, messaging, broadcast, etc., to multiple wirelessusers. The communications system 100 may enable multiple wireless usersto access such content through the sharing of system resources,including wireless bandwidth. For example, the communications systems100 may employ one or more channel access methods, such as code divisionmultiple access (CDMA), time division multiple access (TDMA), frequencydivision multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrierFDMA (SC-FDMA), and the like.

As shown in FIG. 1A, the communications system 100 may include wirelesstransmit/receive units (WTRUs) 102 a, 102 b, 102 c, 102 d, a radioaccess network (RAN) 104, a core network 106, a public switchedtelephone network (PSTN) 108, the Internet 110, and other networks 112,though it will be appreciated that the disclosed embodiments contemplateany number of WTRUs, base stations, networks, and/or network elements.Each of the WTRUs 102 a, 102 b, 102 c, 102 d may be any type of deviceconfigured to operate and/or communicate in a wireless environment. Byway of example, the WTRUs 102 a, 102 b, 102 c, 102 d may be configuredto transmit and/or receive wireless signals and may include userequipment (UE), a mobile station, a fixed or mobile subscriber unit, apager, a cellular telephone, a personal digital assistant (PDA), asmartphone, a laptop, a netbook, a personal computer, a wireless sensor,consumer electronics, and the like.

The communications systems 100 may also include a base station 114 a anda base station 114 b. Each of the base stations 114 a, 114 b may be anytype of device configured to wirelessly interface with at least one ofthe WTRUs 102 a, 102 b, 102 c, 102 d to facilitate access to one or morecommunication networks, such as the core network 106, the Internet 110,and/or the networks 112. By way of example, the base stations 114 a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a HomeNode B, a Home eNode B, a site controller, an access point (AP), awireless router, and the like. While the base stations 114 a, 114 b areeach depicted as a single element, it will be appreciated that the basestations 114 a, 114 b may include any number of interconnected basestations and/or network elements.

The base station 114 a may be part of the RAN 104, which may alsoinclude other base stations and/or network elements (not shown), such asa base station controller (BSC), a radio network controller (RNC), relaynodes, etc. The base station 114 a and/or the base station 114 b may beconfigured to transmit and/or receive wireless signals within aparticular geographic region, which may be referred to as a cell (notshown). The cell may further be divided into cell sectors. For example,the cell associated with the base station 114 a may be divided intothree sectors. Thus, in one embodiment, the base station 114 a mayinclude three transceivers, i.e., one for each sector of the cell. Inanother embodiment, the base station 114 a may employ multiple-inputmultiple output (MIMO) technology and, therefore, may utilize multipletransceivers for each sector of the cell.

The base stations 114 a, 114 b may communicate with one or more of theWTRUs 102 a, 102 b, 102 c, 102 d over an air interface 116, which may beany suitable wireless communication link (e.g., radio frequency (RF),microwave, infrared (IR), ultraviolet (UV), visible light, etc.). Theair interface 116 may be established using any suitable radio accesstechnology (RAT).

More specifically, as noted above, the communications system 100 may bea multiple access system and may employ one or more channel accessschemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. Forexample, the base station 114 a in the RAN 104 and the WTRUs 102 a, 102b, 102 c may implement a radio technology such as Universal MobileTelecommunications System (UMTS) Terrestrial Radio Access (UTRA), whichmay establish the air interface 116 using wideband CDMA (WCDMA). WCDMAmay include communication protocols such as High-Speed Packet Access(HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed DownlinkPacket Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).

In another embodiment, the base station 114 a and the WTRUs 102 a, 102b, 102 c may implement a radio technology such as Evolved UMTSTerrestrial Radio Access (E-UTRA), which may establish the air interface116 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A).

In other embodiments, the base station 114 a and the WTRUs 102 a, 102 b,102 c may implement radio technologies such as IEEE 802.16 (i.e.,Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000,CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), InterimStandard 95 (IS-95), Interim Standard 856 (IS-856), Global System forMobile communications (GSM), Enhanced Data rates for GSM Evolution(EDGE), GSM EDGE (GERAN), and the like.

The base station 114 b in FIG. 1A may be a wireless router, Home Node B,Home eNode B, or access point, for example, and may utilize any suitableRAT for facilitating wireless connectivity in a localized area, such asa place of business, a home, a vehicle, a campus, and the like. In oneembodiment, the base station 114 b and the WTRUs 102 c, 102 d mayimplement a radio technology such as IEEE 802.11 to establish a wirelesslocal area network (WLAN). In another embodiment, the base station 114 band the WTRUs 102 c, 102 d may implement a radio technology such as IEEE802.15 to establish a wireless personal area network (WPAN). In yetanother embodiment, the base station 114 b and the WTRUs 102 c, 102 dmay utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE,LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 1A,the base station 114 b may have a direct connection to the Internet 110.Thus, the base station 114 b may not be required to access the Internet110 via the core network 106.

The RAN 104 may be in communication with the core network 106, which maybe any type of network configured to provide voice, data, applications,and/or voice over internet protocol (VoIP) services to one or more ofthe WTRUs 102 a, 102 b, 102 c, 102 d. For example, the core network 106may provide call control, billing services, mobile location-basedservices, pre-paid calling, Internet connectivity, video distribution,etc., and/or perform high-level security functions, such as userauthentication. Although not shown in FIG. 1A, it will be appreciatedthat the RAN 104 and/or the core network 106 may be in direct orindirect communication with other RANs that employ the same RAT as theRAN 104 or a different RAT. For example, in addition to being connectedto the RAN 104, which may be utilizing an E-UTRA radio technology, thecore network 106 may also be in communication with another RAN (notshown) employing a GSM radio technology.

The core network 106 may also serve as a gateway for the WTRUs 102 a,102 b, 102 c, 102 d to access the PSTN 108, the Internet 110, and/orother networks 112. The PSTN 108 may include circuit-switched telephonenetworks that provide plain old telephone service (POTS). The Internet110 may include a global system of interconnected computer networks anddevices that use common communication protocols, such as thetransmission control protocol (TCP), user datagram protocol (UDP) andthe internet protocol (IP) in the TCP/IP internet protocol suite. Thenetworks 112 may include wired or wireless communications networks ownedand/or operated by other service providers. For example, the networks112 may include another core network connected to one or more RANs,which may employ the same RAT as the RAN 104 or a different RAT.

Some or all of the WTRUs 102 a, 102 b, 102 c, 102 d in thecommunications system 100 may include multi-mode capabilities, i.e., theWTRUs 102 a, 102 b, 102 c, 102 d may include multiple transceivers forcommunicating with different wireless networks over different wirelesslinks. For example, the WTRU 102 c shown in FIG. 1A may be configured tocommunicate with the base station 114 a, which may employ acellular-based radio technology, and with the base station 114 b, whichmay employ an IEEE 802 radio technology.

FIG. 1B is a system diagram of an example WTRU 102. As shown in FIG. 1B,the WTRU 102 may include a processor 118, a transceiver 120, atransmit/receive element 122, a speaker/microphone 124, a keypad 126, adisplay/touchpad 128, non-removable memory 106, removable memory 132, apower source 134, a global positioning system (GPS) chip set 136, andother peripherals 138. It will be appreciated that the WTRU 102 mayinclude any sub-combination of the foregoing elements while remainingconsistent with an embodiment.

The processor 118 may be a general purpose processor, a special purposeprocessor, a conventional processor, a digital signal processor (DSP), aplurality of microprocessors, one or more microprocessors in associationwith a DSP core, a controller, a microcontroller, Application SpecificIntegrated Circuits (ASICs), Field Programmable Gate Array (FPGAs)circuits, any other type of integrated circuit (IC), a state machine,and the like. The processor 118 may perform signal coding, dataprocessing, power control, input/output processing, and/or any otherfunctionality that enables the WTRU 102 to operate in a wirelessenvironment. The processor 118 may be coupled to the transceiver 120,which may be coupled to the transmit/receive element 122. While FIG. 1Bdepicts the processor 118 and the transceiver 120 as separatecomponents, it will be appreciated that the processor 118 and thetransceiver 120 may be integrated together in an electronic package orchip.

The transmit/receive element 122 may be configured to transmit signalsto, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, thetransmit/receive element 122 may be an antenna configured to transmitand/or receive RF signals. In another embodiment, the transmit/receiveelement 122 may be an emitter/detector configured to transmit and/orreceive IR, UV, or visible light signals, for example. In yet anotherembodiment, the transmit/receive element 122 may be configured totransmit and receive both RF and light signals. It will be appreciatedthat the transmit/receive element 122 may be configured to transmitand/or receive any combination of wireless signals.

In addition, although the transmit/receive element 122 is depicted inFIG. 1B as a single element, the WTRU 102 may include any number oftransmit/receive elements 122. More specifically, the WTRU 102 mayemploy MIMO technology. Thus, in one embodiment, the WTRU 102 mayinclude two or more transmit/receive elements 122 (e.g., multipleantennas) for transmitting and receiving wireless signals over the airinterface 116.

The transceiver 120 may be configured to modulate the signals that areto be transmitted by the transmit/receive element 122 and to demodulatethe signals that are received by the transmit/receive element 122. Asnoted above, the WTRU 102 may have multi-mode capabilities. Thus, thetransceiver 120 may include multiple transceivers for enabling the WTRU102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, forexample.

The processor 118 of the WTRU 102 may be coupled to, and may receiveuser input data from, the speaker/microphone 124, the keypad 126, and/orthe display/touchpad 128 (e.g., a liquid crystal display (LCD) displayunit or organic light-emitting diode (OLED) display unit). The processor118 may also output user data to the speaker/microphone 124, the keypad126, and/or the display/touchpad 128. In addition, the processor 118 mayaccess information from, and store data in, any type of suitable memory,such as the non-removable memory 106 and/or the removable memory 132.The non-removable memory 106 may include random-access memory (RAM),read-only memory (ROM), a hard disk, or any other type of memory storagedevice. The removable memory 132 may include a subscriber identitymodule (SIM) card, a memory stick, a secure digital (SD) memory card,and the like. In other embodiments, the processor 118 may accessinformation from, and store data in, memory that is not physicallylocated on the WTRU 102, such as on a server or a home computer (notshown).

The processor 118 may receive power from the power source 134, and maybe configured to distribute and/or control the power to the othercomponents in the WTRU 102. The power source 134 may be any suitabledevice for powering the WTRU 102. For example, the power source 134 mayinclude one or more dry cell batteries (e.g., nickel-cadmium (NiCd),nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion),etc.), solar cells, fuel cells, and the like.

The processor 118 may also be coupled to the GPS chipset 136, which maybe configured to provide location information (e.g., longitude andlatitude) regarding the current location of the WTRU 102. In additionto, or in lieu of, the information from the GPS chipset 136, the WTRU102 may receive location information over the air interface 116 from abase station (e.g., base stations 114 a, 114 b) and/or determine itslocation based on the timing of the signals being received from two ormore nearby base stations. It will be appreciated that the WTRU 102 mayacquire location information by way of any suitablelocation-determination method while remaining consistent with anembodiment.

The processor 118 may further be coupled to other peripherals 138, whichmay include one or more software and/or hardware modules that provideadditional features, functionality and/or wired or wirelessconnectivity. For example, the peripherals 138 may include anaccelerometer, an e-compass, a satellite transceiver, a digital camera(for photographs or video), a universal serial bus (USB) port, avibration device, a television transceiver, a hands free headset, aBluetooth® module, a frequency modulated (FM) radio unit, a digitalmusic player, a media player, a video game player module, an Internetbrowser, and the like.

FIG. 1C is a system diagram of the RAN 104 and the core network 106according to an embodiment. As noted above, the RAN 104 may employ anE-UTRA radio technology to communicate with the WTRUs 102 a, 102 b, 102c over the air interface 116. The RAN 104 may also be in communicationwith the core network 106.

The RAN 104 may include eNode-Bs 140 a, 140 b, 140 c, though it will beappreciated that the RAN 104 may include any number of eNode-Bs whileremaining consistent with an embodiment. The eNode-Bs 140 a, 140 b, 140c may each include one or more transceivers for communicating with theWTRUs 102 a, 102 b, 102 c over the air interface 116. In one embodiment,the eNode-Bs 140 a, 140 b, 140 c may implement MIMO technology. Thus,the eNode-B 140 a, for example, may use multiple antennas to transmitwireless signals to, and receive wireless signals from, the WTRU 102 a.

Each of the eNode-Bs 140 a, 140 b, 140 c may be associated with aparticular cell (not shown) and may be configured to handle radioresource management decisions, handover decisions, scheduling of usersin the uplink and/or downlink, and the like. As shown in FIG. 1C, theeNode-Bs 140 a, 140 b, 140 c may communicate with one another over an X2interface.

The core network 106 shown in FIG. 1C may include a mobility managementgateway (MME) 142, a serving gateway 144, and a packet data network(PDN) gateway 146. While each of the foregoing elements are depicted aspart of the core network 106, it will be appreciated that any one ofthese elements may be owned and/or operated by an entity other than thecore network operator.

The MME 142 may be connected to each of the eNode-Bs 142 a, 142 b, 142 cin the RAN 104 via an Si interface and may serve as a control node. Forexample, the MME 142 may be responsible for authenticating users of theWTRUs 102 a, 102 b, 102 c, bearer activation/deactivation, selecting aparticular serving gateway during an initial attach of the WTRUs 102 a,102 b, 102 c, and the like. The MME 142 may also provide a control planefunction for switching between the RAN 104 and other RANs (not shown)that employ other radio technologies, such as GSM or WCDMA.

The serving gateway 144 may be connected to each of the eNode Bs 40 a,140 b, 140 c in the RAN 104 via the Si interface. The serving gateway144 may generally route and forward user data packets to/from the WTRUs102 a, 102 b, 102 c.

The serving gateway 144 may also perform other functions, such asanchoring user planes during inter-eNode B handovers, triggering pagingwhen downlink data is available for the WTRUs 102 a, 102 b, 102 c,managing and storing contexts of the WTRUs 102 a, 102 b, 102 c, and thelike.

The serving gateway 144 may also be connected to the PDN gateway 146,which may provide the WTRUs 102 a, 102 b, 102 c with access topacket-switched networks, such as the Internet 110, to facilitatecommunications between the WTRUs 102 a, 102 b, 102 c and IP-enableddevices.

The core network 106 may facilitate communications with other networks.For example, the core network 106 may provide the WTRUs 102 a, 102 b,102 c with access to circuit-switched networks, such as the PSTN 108, tofacilitate communications between the WTRUs 102 a, 102 b, 102 c andtraditional land-line communications devices. For example, the corenetwork 106 may include, or may communicate with, an IP gateway (e.g.,an IP multimedia subsystem (IMS) server) that serves as an interfacebetween the core network 106 and the PSTN 108. In addition, the corenetwork 106 may provide the WTRUs 102 a, 102 b, 102 c with access to thenetworks 112, which may include other wired or wireless networks thatare owned and/or operated by other service providers.

In LTE, a PDCCH is used by the network to assign PDSCH resources fordownlink transmissions and to grant PUSCH resources for uplinktransmissions to the WTRU. A WTRU may request radio resources for anuplink transmission by sending a scheduling request (SR) to the eNB. TheSR may be transmitted either on dedicated resources on a PUCCH ifconfigured, or using a random access procedure.

A WTRU is granted radio resources by the eNB for a transmission on aPUSCH, indicated in a grant received on the PDCCH or on configuredresources (i.e., a semi persistently scheduled (SPS) UL grant).

A WTRU determines whether or not it needs to act on control signaling ina given sub-frame by monitoring the PDCCH for specific downlink controlinformation (DCI) messages scrambled using a known radio networktemporary identifier (RNTI) in specific locations, (i.e., a searchspace), using different combinations of physical resources (i.e.,control channel elements (CCEs)) based on aggregation levels (ALs). EachAL corresponds to either 1, 2, 4, or 8 CCEs. A CCE comprises 36quadrature phase shift keying (QPSK) symbols, or 72 channel coded bits.

The PDCCH is separated in two distinct regions. The set of CCE locationsin which a WTRU may find DCIs it needs to act on is referred to as asearch space. The search space is split into the common search space andWTRU-specific search space. The common search space is common to allWTRUs monitoring a given PDCCH, while the WTRU-specific search spacediffers from one WTRU to another. Both search spaces may overlap for agiven WTRU in a given sub-frame as this is a function of therandomization function, and this overlap differs from one sub-frame toanother.

The set of CCE locations that makes up the common search space and itsstarting point is a function of the cell identity and the sub-framenumber. For LTE R8/9, DCIs may be sent with AL4 (4 CCEs) or AL8 (8 CCEs)in the common search space. For a sub-frame for which the WTRU monitorsthe PDCCH, the WTRU may attempt to decode 2 DCI format sizes (e.g., DCIformats 1A and 1C, and DCI format 3A used for power control) in up to 4different sets of 4 CCEs for AL4 (i.e., 8 blind decoding) and up to 2different sets of 8 CCEs for AL8 (i.e., 4 blind decoding) for a total ofat most 12 blind decoding attempts in the common search space.

The common search space corresponds to CCEs 0-15, implying four decodingcandidates for AL4 (i.e., CCEs 0-3, 4-7, 8-11, and 12-15) and twodecoding candidates for AL8 (i.e., CCEs 0-7, and 8-15).

The set of CCE locations that makes up the WTRU-specific search spaceand its starting point is a function of the WTRU identity and thesub-frame number. For LTE R8/9, DCIs may be sent with AL1, AL2, AL4, orAL8 in the WTRU-specific search space. For a sub-frame for which theWTRU monitors the PDCCH, the WTRU may attempt to decode 2 DCI formats inup to 6 different CCES for AL1 (i.e., 12 blind decoding), up to 6different sets of 2 CCEs for AL2 (i.e., 12 blind decoding), up to 2different sets of 8 CCEs for AL8 (i.e., 4 blind decoding), and up to 2different sets of 8 CCEs for AL8 (i.e., 4 blind decoding) for a total ofat most 32 blind decoding attempts in the WTRU-specific search space.

Depending on the WTRU's connection to the network, capabilities andsupported features, the WTRU may monitor one or more RNTIs for grants,assignments, and other control information from the eNB. The WTRU maymonitor at least one of a system information RNTI (SI-RNTI), a pagingRNTI (P-RNTI), a random access RNTI (RA-RNTI), a multimediabroadcast/multicast services (MBMS) RNTI (M-RNTI), a cell RNTI (C-RNTI),a temporary C-RNTI, a semi-persistent scheduling C-RNTI (SPS-C-RNTI),etc. The SI-RNTI is cell-specific, and is used to indicate scheduling ofsystem information on a PDSCH in the common search space. The P-RNTI maybe assigned to multiple WTRUs for decoding of the paging notification(e.g., in IDLE mode) in the common search space. The RA-RNTI is used toindicate scheduling of the random access response on a PDSCH, andidentifies which time-frequency resource was used by a WTRU to transmitthe random access preamble. The M-RNTI is cell-specific and is used todecode the notification of a change on the MBMS control channel (MCCH)in the common search space. The C-RNTI is a WTRU-specific RNTI used todecode a PDCCH for contention-free grants and assignments, for example,for DCIs in the WTRU-specific search space. The temporary C-RNTI may beused for decoding of messages for the contention-based procedure, and/orbefore the WTRU gets assigned its own C-RNTI. The SPS-C-RNTI may be usedto activate a semi-persistent downlink allocation on a PDSCH or uplinkgrant on a PUSCH in the WTRU-specific search space. A transmit powercontrol (TPC)-PUSCH-RNTI and a TPC-PUCCH-RNTI may be used for powercontrol of the PUSCH and PUCCH, respectively.

In LTE, the network may configure a WTRU with parameters fordiscontinuous reception (DRX). DRX is a functionality that allows a WTRUto not monitor and decode the PDCCH, for the purpose of lowering WTRUpower consumption. The DRX functionality relies on a specific set ofrules based on PDCCH activity for a number of specific RNTIs. Theserules ensure that the network and the WTRU are synchronized with respectto when the WTRU may be reached using the control signaling. When DRX isconfigured, the WTRU may monitor the PDCCH at least when in DRX activetime (with the exception of a configured measurement gap).

Within a transceiver (i.e., WTRU), power consumption is distributedbetween the baseline baseband, the baseband, the receiver and thetransmitter. While the baseline baseband consumes little power, each ofthe three other components corresponds approximately to ⅓ of the totalpower consumption. The startup times for each also differ, and turningon the baseband component may require more than a few tens of ms,including synchronization with network signals.

From a processing requirement and implementation perspective, given thatin a subframe for which the WTRU monitors PDCCH for DL assignments, thesymbols containing user data (e.g., PDSCH) follow the symbols used forthe L1 control region (e.g., the PDCCH), and the processing of L1signaling is not instantaneous. A WTRU may buffer at least part of thePDSCH symbols, at least until it can complete the processing of the L1signaling and can determine whether or not there is a DL transmissionaddressed to the WTRU on the PDSCH in that subframe. Therefore, thebenefit of DRX goes beyond saving some processing for the PDCCH. Forsubframes in which the WTRU is not required to monitor PDCCH for ULgrants and DL assignments, a WTRU may elect to turn off at least partsof its transceiver (Tx/Rx) circuitry, including memory components and/orparts of the baseband component (if the number of subframes for whichthe WTRU will not monitor PDCCH is sufficiently large, for example, afew 10 s of ms). The RNTIs for which the WTRU applies the above includeC-RNTI, TPC-PUCCH-RNTI, TPC-PUSCH-RNTI, SPS-C-RNTI, etc.

The idea described herein may additionally be applicable to a DRXfunction where additional RNTI(s) are considered in later evolutions ofthe specifications, and is thus not precluded by this document.

In LTE, a WTRU may initiate the random access procedure when the WTRUmakes an initial access to the network to establish an RRC connection,when the WTRU accesses the target cell during a handover, when the WTRUperforms the RRC connection re-establishment procedure, when the WTRU isinstructed by the network to perform the random access procedure (i.e.,by PDCCH random access order, for example, for DL data arrival), whenthe WTRU makes a scheduling request, but has no dedicated resources on aPUCCH for the request, (e.g., when the WTRU has new UL data to transmitthat has a higher priority than existing data in its buffer), or thelike.

Depending on whether or not the WTRU is assigned dedicated RACHresources (e.g., a specific preamble and/or PRACH resource), the randomaccess procedure may be either contention-free random access (CFRA) orcontention-based random access (CBRA). For the random access, a WTRUsends a preamble on a resource of the physical random access channel(PRACH). The WTRU then receives a random access response (RAR). The RARcontains a grant for an uplink transmission and a timing advance command(TAC). For the CBRA, for contention resolution, the WTRU determineswhether or not it successfully completed the RACH procedure based oneither C-RNTI on a PDCCH or WTRU contention resolution identity on aDL-SCH.

In LTE, a WTRU may be configured, using RRC, with dedicated resourcesfor the transmission of CQI/PMI/RI reports and for scheduling requests(SR). In addition, a WTRU may be configured with dedicated uplinkresources for SPS, as well as with an uplink PUCCH resource for HARQacknowledgement (ACK) for a corresponding DL SPS configuration. Thenetwork may assign a WTRU with dedicated SRS resources to assistscheduling decisions in allocation of uplink resources for PUSCHtransmissions.

In LTE, in order to maintain the orthogonality among uplinktransmissions from a plurality of WTRUs, the uplink transmissions fromdifferent WTRUs to the eNB within the same subframe should beapproximately time-aligned, where the margin of error should be withinthe cyclic prefix length. The cyclic prefix is a guard interval in thetime domain that is added to each symbol to handle channel delayspreading. For LTE, the generic frame structure with normal cyclicprefix length contains 7 symbols, and the cyclic prefix length is 5.2 μsfor the first symbol and 4.7 μs for the other symbols of the frame. Forlarger cells, an extended prefix may be configured. The timing advanceis a negative offset at the mobile terminal between the start of areceived downlink subframe and a transmitted uplink subframe (i.e., thesubframe for the uplink transmission starts ahead of the downlinksubframe at the mobile terminal). The offset may be adjusted by thenetwork using timing advance command (TAC) signaling, and suchadjustments are based on previous uplink transmissions by the WTRU,including sounding signals (SRS) and any other uplink transmissions.

In LTE, before a WTRU can perform uplink transmissions for periodic SRSor an uplink transmission on either a PUCCH or a PUSCH, the WTRU needsto have proper timing alignment with the network. Uplink synchronizationis initially achieved using the RACH procedure, and the networksubsequently transmits a TAC in the downlink to maintain proper timingalignment. A WTRU (re)starts the timing advance timer (TAT) upon receiptof the TAC. A TAC may be received in the RAR during the RA procedure orin a Timing Advance MAC Control Element (CE).

When the TAT is running, the WTRU may transmit on a PUCCH resource in asubframe for which the WTRU does not perform a PUSCH transmission(single carrier property). PUCCH resources are dynamically allocated forHARQ ACK feedback for a PDSCH transmission in a frequency/time sharedresource of the PUCCH region. The WTRU determines which PUCCH resourceto use based on the first CCE of the DCI received on a PDCCH whichindicated the PDSCH assignment.

The TAT may expire for a synchronized WTRU when it does not receive aTAC from the network for at least period equal to the configured valueof the TAT (i.e.,the timeAlignmentTimer, which ranges from 500 ms up to10,240 ms, if enabled). A WTRU may not receive a TAC in case all TACsare lost during that period. Alternatively, a WTRU may not receive a TACif the network does not send any, for the purpose of implicitlyreleasing dedicated uplink resources when the network no longerschedules the WTRU for new transmissions. The validity of the WTRU'stiming advance is controlled by the eNB.

When the TAT expires, the WTRU releases its dedicated uplink resources,i.e., any configured SRS resources as well as PUCCH resources for SR andCQI/PMI/RI, and any configured downlink and uplink SPS resources.Additionally, the WTRU may not be allowed to perform any PUCCH or PUSCHtransmission once it is not considered synchronized with the network.This is to avoid possible interference to the transmission of otherWTRUs. In addition, it provides implicit means for the scheduler torevoke dedicated uplink resources, simply by having the TAT expiringfollowing the absence of TACs from the network.

Signaling radio bearers (SRBs) are radio bearers used for thetransmission of RRC and NAS messages. SRB0 is used for RRC messagesusing a common control channel (CCCH), SRB1 is for RRC messages (with apiggybacked NAS message as well) and for NAS messages prior toestablishment of SRB2 using a dedicated control channel (DCCH). SRB2 isfor NAS messages and is configured after activation of security. Oncesecurity is activated, all RRC messages on SRB1 and SRB2 are integrityprotected and ciphered. Data radio bearers (DRBs) are radio bearers usedfor the transmission of user plane data (e.g., IP packets).

One way to improve the user plane latency for synchronized WTRUs (i.e.,WTRUs that have a valid timing alignment) but do not have a valid ULgrant, is to use a contention-based (CB) method. The network mayadvertise (otherwise unused) uplink resources on a PDCCH to one or moreWTRUs connected to the network. A special RNTI, (i.e., contention-based”RNTI (CB-RNTI)), may be assigned to the WTRU(s) for this purpose, forexample, during the radio configuration of the WTRU, and the sameCB-RNTI may be signaled to multiple WTRUs.

The non-access stratum (NAS) protocol runs between a WTRU and a mobilitymanagement entity (MME) in the core network. The NAS is responsible for(among other things) performing a public land mobile network (PLMN)selection, registration (via attach or tracking area update procedure)to the network (i.e., the selected PLMN), requisition of IP address(es)and thereby bearers for user plane operation, and transition from idleto connected mode.

When a WTRU powers on, it starts in EPS mobility management(EMM)-DEREGISTERED state (as it is not yet registered to the network).After a PLMN/cell has been chosen, the WTRU/NAS attempts to register tothe network, thereby requesting an RRC connection to transmit the firstNAS message (i.e., the attach message).

After the first NAS message is transmitted (when in RRC connected state)and the first NAS response is received, the NAS is then said to be inEMM-Connected mode. An RRC connection is needed for an NAS connection tobe established (i.e., for the WTRU to be in EMM-Connected mode).

When the WTRU is in an idle mode, both the WTRU and the MME maintain theWTRU's active EPS bearer context such that resources for these activebearers will be setup upon transition to a connected mode. In LTE, theWTRU may have at least a default bearer active, and while in a connectedmode, corresponding resource (on the radio and S1-U) for at least thisbearer may be setup.

The NAS service request procedure is used to bring a WTRU from idle toconnected mode. When this transition occurs, the network will setupresources (DRBs and S1-U) for active EPS bearer context that is retainedat the MME.

When the WTRU goes from idle to connected mode, all or a subset of thededicated bearers may not have resources (DRBs) setup, and the WTRU RRCinforms the NAS about those that were deactivated (DRBs not setup) andthus the NAS deactivates the corresponding EPS bearers. However, theWTRU remains in the system and operates with the default bearer (but isallowed to request dedicated bearers if need be). The WTRU's RRC informsthe NAS about the bearers that do not have any resources setup. If thedefault bearer is one of them, the NAS performs a local detach and theWTRU needs to re-attach to the system for operation.

The NAS service request procedure is initiated in idle mode (with theexception of circuit switched (CS) fallback). A WTRU that is already ina connected mode (RRC and EMM) may not send an NAS service requestmessage (except for CS fallback). The NAS service request procedure isdeemed successful by the WTRU, (i.e., NAS), upon lower layer indicationthat the DRBs have been setup, or upon the reception of an NAS servicereject message from the MME.

In LTE, a service that generates user plane data may be associated witha a radio access bearer (RAB). A WTRU may be configured with one or moreRABs, and different RAB may terminate in different PDN gateway (PGW) inthe core network.

An RAB may be associated to a DRB. An RAB may be associated with aspecific set of QoS characteristics. The network configures a DRB (e.g.,with parameters such as logical channel priority, prioritized bit rate(PBR), and packet data convergence protocol (PDCP) service data unit(SDU) discard timer, etc.) according to the desired level of QoS.

A DRB may be associated to either a default EPS bearer, or to adedicated bearer. Applications use bearers (both default and dedicated)according to the given QoS supported by those bearers. Packet filtersmay be used in the WTRU (e.g., for uplink data) and in the CN (e.g., fordownlink data) to determine how to associate an IP packet with a givenRAB.

In LTE, a service may generate user plane data that require differentQoS levels. For example, a voice over IP (VoIP) application may generatean RTP voice/audio stream using a given UDP port, and exchange RTCPcontrol packets using a different UDP port. In this case, the RTP flowmay use a first RAB, while the RTCP flow may use a second RAB. The WTRUthus determines for each generated IP packet what RAB the packet shouldbe transmitted on. It may be realized using packet filters or trafficflow template (TFTs). The WTRU may be configured with packet filters orTFTs by the network.

FIG. 2 shows an example bearer service architecture wherein packetfilters are used to direct packets to the relevant radio bearer. In thisexample, packets are either sent to one of the available dedicatedbearers or the default bearer, or they may be discarded if they do notmatch the flow characteristics as defined by the relevant TFT. TFTs areprovided by the network (e.g., PGW) when a CreateSessionResponse messageis sent in response to CreateSessionRequest message. The message may besent, for example, when a SGW changes, e.g., during handover, or whenthe WTRU requests PDN connectivity either during an attach procedure ora PDN connectivity request procedure.

In LTE, one or more EPS bearer(s) may be setup or removed for a WTRUgiven using higher layer procedures. The WTRU may maintain any defaultEPS bearer(s) and any other associated dedicated bearer(s) in the WTRU'scontext as long as the WTRU is attached to the network. In particular,EPS bearers are maintained in the WTRU's context independently of thestate of the RRC connection, (i.e., even when in idle mode). EPS bearersare removed when the WTRU performs the detach procedure from thenetwork.

In LTE, when the WTRU releases the RRC connection, any radio accessbearers (SRBs, DRBs) may be released (e.g., the S1u connection andassociated context between thee eNB and the SGW is released).

In the connection-less transmission, small data packets may be carriedover by the control plane, following a signaling RRC connectionestablishment message. This type of data transmission may be viewed as aconnectionless approach for packet transfer in a cellular networkbecause the message is conveyed without setting up a user planeconnection. The end-user packet may be sent along with a large headerthat enables subsequent processing of the packet by the receiving node(e.g., the end-user packet is embedded within an NAS/AS control planemessage).

A WTRU may send data in any NAS message, for example, by adding aninformation element (IE) that may carry the data part. The IE may beadded, for example, to the attach request message, the service requestmessage, the PDN connectivity request (in the LTE case) message, atracking area update (TAU) request message, or the like. If the PDNconnectivity request message is included in the attach message, the WTRUmay indicate, (e.g., by using a specific value given to the EPS beareridentity), that no EPS bearer/PDP context may be set up. In addition,the small data may be carried in a container within the ProtocolConfiguration Options IE. Similarly methods may be used to transmit datain the downlink direction.

A new IE “Mtc-datagram-info” may be included in an NAS message (e.g., aMM message or EMM message, etc.) for the purpose of carrying smallvolume of data for machine-type communication (MTC) devices or otherapplications to enhance the capability of the original NAS message forcompleting both the administrative and the data transfer function inone. This IE may contain the destination address, routing information,small data type, end-of-chain parameter indicating whether this is thelast unit in a chain of small data transfer units to one destination,security information, or the like.

A WTRU may be configured in numerous different manners, such thattradeoffs may be achieved between data transfer latency, powerconsumption, control signaling overhead, and network efficiency. Forexample, a WTRU may be in RRC_CONNECTED for a long period of time forthe benefit of low control signaling overhead and low data transferlatency, but at the expense of battery usage and network resourceefficiency when dedicated resources remains committed. Conversely, aWTRU may instead periodically transit between RRC_CONNECTED and RRC_IDLEstates for the benefit of low power consumption, but at the cost ofincreased data transfer latency and additional control signalingoverhead.

WTRUs may support a wide variety of applications, often in parallel,each with different traffic characteristics and requirements. Many suchapplications are agnostic to the technology used for transmission oftheir data, and some applications may not be very well suited forwireless transmissions. For example, in case an application generatingdata traffic with relatively long periods of low-volume at intermittentintervals, a WTRU may be idle for a long period while it may stillregularly connect to the network to exchange small amounts of data.

In case such applications remain active over a long period of time,background traffic may be generated at regular intervals. Embodimentsare disclosed herein for the methods such that a WTRU may remain readyfor transmitting small amounts of data, while maximizing usage ofbattery and network resources.

A WTRU implementing the embodiments disclosed herein are referred to as“dormant WTRU,” “WTRU in dormant mode,” or “WTRU using a dormantbehavior,” which will be used interchangeably. The WTRU in a dormantmode may be realized by using a new RRC state (e.g., RRC_DORMANT).Alternatively, the dormant mode may be realized using additionalprocedures in the RRC idle state, (i.e., defining a sub-state withmodifications to the conventional RRC_IDLE state), or using additionalprocedures in the RRC connected state (i.e., defining a sub-state withmodification to the conventional RRC_CONNECTED state). Alternatively,the dormant mode may be realized using additional power savings methods.Such procedures and methods may include using a second set ofconfiguration parameters applicable to the applicable behavior. Theterms “dormant mode”, “RRC_DORMANT” and “RRC_DORMANT state” will be usedto refer to the behavior or state of the WTRU or network entity inaccordance with any one of these realizations.

FIG. 3 shows state transitions among RRC_IDLE 310, RRC_CONNECTED 320,and RRC_DORMANT 330 (i.e., a new RRC state) in accordance with oneembodiment. It should be noted that FIG. 3 shows the case that uses thenew RRC state as an example realization of the dormant mode, and thedormant mode may be realized by defining a sub-state of the RRC_IDLE 310or RRC_CONNECTED 320 as stated above. The WTRU may transition among theRRC states based on predetermined implicit or explicit triggers, whichwill be explained in detail below.

A WTRU is in RRC_CONNECTED 320 when an RRC connection has beenestablished. If no RRC connection is established, the WTRU is inRRC_IDLE state 310. In the RRC_IDLE state 310, a WTRU may be configuredwith a WTRU-specific DRX, and performs WTRU-controlled mobility. TheWTRU monitors a paging channel to detect incoming calls, systeminformation change, etc. The WTRU performs neighboring cell measurementsand cell re-selection, acquires system information, and performs loggingof available measurements.

In the RRC_CONNECTED state 320, a WTRU may transmit and/or receiveunicast data. At lower layers, the WTRU may be configured with aWTRU-specific DRX. A network controlled mobility, (i.e. handover) isperformed in the RRC_CONNECTED state 320. The WTRU monitors a pagingchannel and/or system information block type 1 contents to detect systeminformation change. The WTRU monitors control channels associated withthe shared data channel to determine if data is scheduled for it,provides channel quality and feedback information, performs neighboringcell measurements and measurement reporting, and the like.

In the RRC_DORMANT state 330, a WTRU, unlike RRC_IDLE 310, may send ascheduling request using a dedicated PRACH, and may transmit and receiveunicast data using dedicated resources (e.g., using C-RNTI). In theRRC_DORMANT state 330, the WTRU, unlike RRC_CONNECTED 320, may performWTRU-controlled mobility (e.g., WTRU-autonomous cell selection andreselection), and scheduling occasions for the WTRU may be adjusted tomatch paging cycle.

A WTRU may be requested by the network (using an L3 message) to move tothe RRC_DORMANT state 330 (e.g., to allow network-controlled WTRUtransitions to a power saving state). The WTRU may be configured with,or may autonomously derive, one or more DRX configurations, either forL3 DRX operation or L2 DRX operation. An additional L3 DRX may beconfigured in RRC_DORMANT 330 which has precedence over an L2 DRX (e.g.,to avoid excessive radio link measurement requirements). The WTRU maymaintain at least a part of its PUCCH configuration (e.g., configurationfor CQI reporting) and/or dedicated SRS configuration even whenunsynchronized (e.g., to avoid the need of RRC reconfiguration for everyunicast data transfers). The WTRU may use cell reselection duringperiods for which it is not scheduled actively by the network forunicast transfers, while it may use measurement reporting configurationotherwise. Cell re-selection may trigger a transition to the RRC_IDLEstate 310 and may trigger an initial access in the target cell.

In the RRC_DORMANT state 330, the WTRU may use a contention-based grantto transmit uplink data (e.g., to avoid latency of the schedulingrequest). The WTRU may perform an uplink transmission, regardless of theuplink timing synchronization, in a special subframe to avoidmaintaining timing alignment, which will be explained in detail below.Alternatively, the WTRU may perform a contention-free random access(CFRA) transmission in a WTRU-specific subframe to request uplinkresources for an uplink transfer that corresponds to the dormant mode,to gain uplink timing synchronization, and/or to acknowledge downlinktransmission(s).

Upon transition to a dormant mode, the RRC may inform upper layers(e.g., NAS) of such transition. For example, the RRC may indicate to theNAS that a dormant mode is activated (e.g., upon a transition to theRRC_DORMANT state 330). When the NAS receives such indication, it mayinitiate session management signaling e.g., to install packet filters(in traffic flow templates (TFTs)), such that the WTRU may determinewhat packets from what DRB may be transmitted using what dormant moderadio bearer (XRB) of the WTRU's configuration. An XRB is conceptuallyrepresented as a radio bearer that is configured for user plane data ina dormant mode for a specific type of traffic (e.g., low priority,intermittent, background data services).

In another embodiment, the dormant behavior may be realized by modifyingthe idle mode procedures (e.g., in RRC_IDLE state 310). In the modifiedRRC_IDLE state (e.g., in a sub-state of the RRC_IDLE state 310), theWTRU may monitor a PDCCH for paging messages at its WTRU-specific pagingoccasions. The WTRU may request and/or indicate to the network using anL3 message that it moves to RRC_IDLE (e.g., to allow autonomous WTRUtransitions to a power saving state). The WTRU may be requested by thenetwork using an L3 message that it needs to move to RRC_IDLE (e.g., toallow network-controlled WTRU transitions to a power saving state). TheWTRU may maintain at least part of the configuration applicable to theRRC CONNECTED state 320 in the modified RRC_IDLE state (e.g., in asub-state of the RRC_IDLE state 310). The WTRU may maintain at least itssecurity context upon transition to RRC_IDLE (e.g., to avoid the need tore-activate security for the next unicast data transfer). The WTRU maymaintain at least its C-RNTI upon transition to RRC_IDLE (e.g., to avoidthe need to re-assign a C-RNTI using the random access procedure for thenext unicast data transfer). The WTRU may maintain at least part of itsPUCCH configuration (e.g., for CQI reporting or for D-SR) and/ordedicated SRS configuration upon transition to RRC_IDLE and even ifunsynchronized (e.g., to avoid the need of an RRC reconfiguration forthe next unicast data transfers). Cell re-selection may invalidate theconfiguration applicable to the RRC_CONNECTED state and to the dormantmode such as the security context and dedicated configuration (e.g.,PUCCH configuration), and complete the transition to the RRC_IDLE state.A timer-based mechanism may be used to invalidate the security contextand the dedicated configuration (e.g., PUCCH configuration) and tocomplete the transition to the RRC_IDLE state (e.g., if no unicast datatransfer occurs during a period of time, such as since last transfer).

In another embodiment, the dormant mode may be realized by modifying theconnected mode procedures (e.g., in RRC_CONNECTED state). In themodified RRC_CONNECTED state (e.g., in a sub-state of the RRC_CONNECTEDstate), the WTRU may be configured with, or may autonomously derive, oneor more DRX configurations, either for L3 DRX operation or L2 DRXoperation. The WTRU may be configured with L2 DRX for power savings andscheduling occasions, and an additional L3 DRX may be configured whichhas precedence over the L2 DRX (e.g., to avoid excessive radio linkmeasurement requirements). The WTRU may maintain at least part of itsPUCCH configuration (e.g., for CQI reporting or for D-SR) and/ordedicated SRS configuration even when unsynchronized (e.g., to avoid theneed of an RRC reconfiguration for every unicast data transfers).

A new NAS state may be defined to reflect entering or exiting a dormantmode. As an example, the state may be referred to as a dormant mode andmay be realized as either a subset of EMM-IDLE or EMM-CONNECTED mode.The term “EMM-DORMANT” will be used hereafter and this may refer to anNAS dormant mode that may either be a sub-state of EMM-IDLE (e.g.,EMM-IDLE.DORMANT) or a sub-state of EMM-CONNECTED (e.g.,EMM-CONNECTED.DORMANT). This dormant state may be realized as asub-state of EMM-REGISTERED state or EMM-REGISTERED.NORMAL-SERVICEstate.

FIG. 4 shows a diagram of example state transitions at the NAS.EMM-DORMANT 410 defines a WTRU NAS behavior in a dormant mode that maybe realized as a sub-state of EMM-IDLE, EMM-CONNECTED, orEMM-REGISTERED, etc. The state EMM-nonDORMANT 420 indicates that theWTRU is not operating in a dormant mode and may be in EMM-IDLE,EMM-CONNECTED, or EMM-REGISTERED, etc. The NAS transitions betweenEMM-DORMANT 410 and EMM-nonDORMANT based on a trigger or an indicationfrom a lower layer or an MME.

It should be noted that while the embodiments will be described withreference to 3GPP LTE, the embodiments are applicable to any wirelesssystems including, but not limited to, WCDMA, HSUPA, HSDPA, HSPA+,GERAN, IEEE 802.xx, and the like.

Embodiments for enabling and disabling a dormant mode are disclosedhereafter. Whether or not the WTRU may use a dormant mode of operationmay be controlled using one or a combination of any of the followingembodiments.

A WTRU in a connected mode may implicitly determine that it may enable adormant mode of operation using at a least one of the followingembodiments.

A WTRU may transit to a dormant mode on a condition that the NAS of theWTRU transits to a dormant mode (e.g., EMM_DORMANT) and indicates it tothe RRC. The WTRU may transit to a dormant mode (e.g., RRC_DORMANT orRRC_IDLE or RRC_CONNECTED state that supports a dormant mode ofoperation) on a condition that the NAS of the WTRU transmits controlsignaling (e.g., a NAS service request or a NAS service update) thatrequests setup for resources for the dormant mode operation, (forexample, one or more EPS RAB(s) that maps to XRB(s)). Alternatively, theWTRU may transit to a dormant mode on a condition that the NAS of theWTRU receives control signaling that sets up resources for the dormantmode operation, (e.g., one or more EPS RAB(s) that maps to XRB(s)).

Alternatively, the WTRU may transit from a connected mode (e.g., RRCCONNECTED) to a dormant mode (e.g., RRC_DORMANT or RRC_IDLE orRRC_CONNECTED state that supports a dormant mode of operation). Forexample, the WTRU may transit to the dormant mode on a condition ofreception of RRC control signaling, or any control signaling (such as L2MAC signaling) that activates the use of the dormant behavior for theWTRU.

Alternatively, a WTRU may autonomously indicate and/or request a releaseof the RRC connection (e.g., by sending an RRC connection releaserequest message). The WTRU may include additional information in therequest, including traffic characteristics such as at least one ofaverage inter-packet arrival time with or without mean deviation,average inter-burst arrival time with or without mean deviation, averageburst size, buffer fill rate, average packet size, or the like asdescribed herein. The WTRU may include information related to the WTRU'smobility. The WTRU may include a selection of preferred parameters suchas DRX parameters and/or scheduling request parameters, such as an indexcorresponding to parameters selected from a list of availableparameters. The WTRU may autonomously enable the dormant mode as part ofthe RRC connection release request. Alternatively, the WTRU may beinstructed in a message in response to the RRC connection releaserequest to enable the dormant mode. The response message may include aconfiguration or a reconfiguration of the WTRU's parameters to be usedwhile operating with the dormant mode.

Alternatively, the WTRU may enable a dormant mode on a condition thatthe WTRU has not received any control signaling (e.g., for scheduling ofdedicated transmissions) for a consecutive number (which may beconfigurable) of DRX cycles, or on a condition that the WTRU receives aMAC DRX control element (CE) indicating that a different (e.g. possiblylonger) DRX cycle may be used. The WTRU may receive signaling (e.g. aMAC CE) that indicates an index to a DRX configuration from a list ofavailable DRX configurations. For example, the indication may correspondto a different (e.g., non-default) configuration for other configurationaspects such as a RACH configuration and/or a PUCCH configuration (e.g.,for D-SR).

Alternatively, the WTRU may enable a dormant mode on a condition thatthe WTRU has not been scheduled for a certain period of time and/or thePDCCH activity is below a certain threshold (which may be configurable).

Alternatively, the WTRU may enable a dormant mode based on a timer,(e.g., a certain number of subframe(s) have elapsed). The timer may, forexample, be restarted based on the WTRU's scheduling activity. Forexample, the timer may be restarted on a condition that the WTRUsuccessfully decodes PDCCH control signaling (e.g., scrambled with theC-RNTI). Alternatively, the timer may correspond to the number of DRXcycles (if configured) without receiving any control signaling.Alternatively, the timer may be restarted based on the WTRU's bufferstatus. For example, the timer may be restarted on a condition that theuplink buffer of the WTRU is empty. This may be applied to the bufferstatus for a subset of the configured logical channel groups (LCGs)and/or logical channels (LCHs) and some data, (e.g., data for one ormore LCH(s) that correspond to a specific QoS/service) may be excluded.Alternatively, the timer may be restarted based on the WTRU's timingalignment timer (TAT), (e.g., upon expiry of the TAT).

Alternatively, the WTRU may enable a dormant mode on a condition that itno longer has valid uplink timing alignment (e.g., the TAT expires atleast for the primary serving cell of the WTRU).

Alternatively, the WTRU may enable a dormant mode on a condition thatthe WTRU RRC is reconfigured including at least one XRB as part of theWTRU's configuration.

Alternatively, the WTRU may enable a dormant mode on a condition that aWTRU has no data available for transmission. For example, the WTRU mayenable a dormant mode on a condition that the WTRU indicates emptybuffers in a PUSCH transmission, for example, by including a paddingbuffer status report (BSR) that reports zero data either for allconfigured DRBs or for DRBs that are not configured as an XRB.Alternatively, the WTRU may enable a dormant mode after a predeterminedamount of time, for example, from the subframe in which the BSR wasincluded in a transmission, or from the subframe in which the WTRUreceived a HARQ ACK for the transmission. Alternatively, the WTRU mayenable a dormant mode on a condition that the WTRU determines that thedata arrival rate for at least one DRB (e.g., XRB(s) and when other DRBshave empty buffers during that time) is below a certain threshold (whichmay be configurable). Alternatively, the WTRU may enable a dormant modeon a condition that the WTRU determines that the inter-packet arrivalrate for one or more specific DRB(s) (e.g., XRB(s) and when other DRBshave empty buffers during that time) is above a certain threshold (whichmay be configurable). Alternatively, the WTRU may enable a dormant modeon a condition that a total sum of data is below a certain threshold.

Alternatively, the WTRU may enable a dormant mode on a condition thatthe time elapsed between uplink and/or downlink transmissions (i.e.,inter-packet or inter-burst arrival time) exceeds a certain threshold(which may be configurable). The WTRU may perform such measurements forone or more subset of the configured DRBs. For example, the WTRU maykeep track of inter-packet or inter-burst arrival time for a set of DRBsconfigured as XRBs, if the WTRU has no data for DRBs that are notconfigured as XRBs and/or if such DRBs have been inactive for a certainperiod of time. The WTRU may maintain an average time estimate. The WTRUmay maintain a mean deviation estimate. The WTRU's time estimates may bereset on a condition that transmissions for a signaling radio bearer(SRB) are performed, or transmissions for any RB that is not configuredas an XRB is performed.

Alternatively, the WTRU may enable a dormant mode on a condition thatthe buffer fill rate for uplink and/or downlink transmissions is below acertain threshold (which may be configurable) over a certain period oftime. The WTRU performs such measurements for one or more subset of theconfigured DRBs. For example, the WTRU may keep track of the buffer fillrate for a set of DRBs configured as XRBs, if the WTRU has no data forDRBs that are not configured as an XRB and/or if such DRBs have beeninactive for a certain period of time. The WTRU's buffer fill rateestimates may be reset on a condition that transmissions for SRBs areperformed, or transmissions for any RB that is not configured as an XRBis performed.

A WTRU may implicitly determine that it may disable a dormant mode ofoperation using at a least one of the following embodiments.

The WTRU may transit away from the dormant mode on a condition that theNAS of the WTRU transits away from a dormant mode and indicates it tothe RRC. The WTRU may transit away from the dormant mode on a conditionthat the NAS of the WTRU transmits control signaling (e.g., an NASservice request or an NAS service update) that requests setup forresources for at least one dedicated and/or default bearer (e.g., thatis not associated to an XRB), or on a condition that there is a pendingNAS session management procedure. The WTRU may transit away from thedormant mode on a condition that the NAS of the WTRU receives controlsignaling that sets up resources for at least one dedicated and/ordefault bearer (e.g., that is not associated to an XRB), or on acondition that there is a pending NAS session management procedure.

The WTRU may transit from the dormant mode (e.g., RRC_DORMANT state) orfrom a sub-state of an idle or connected mode that supports a dormantmode of operation to a connected mode (e.g. RRC CONNECTED state), uponreception of RRC control signaling. For example, a WTRU may disable thedormant mode on a condition that upper layers (e.g., NAS) request atransition to a connected mode (e.g., RRC CONNECTED state) withoutdormancy behavior. The WTRU may use an RRC signaling procedure totransit to a connected mode. For example, the WTRU may perform an RRCconnection request procedure such that it may disable the dormantbehavior and/or transit to an RRC connected state.

Alternatively, the WTRU may disable the dormant mode on a condition thatupper layers (e.g., NAS) request a transition to an idle mode (e.g.,IDLE state without dormancy behavior). Alternatively, the WTRU maydisable the dormant mode on a condition that the WTRU determines that itshould perform an RRC state transition to an idle mode (e.g., IDLE statewithout dormancy behavior), for example, upon detection of a UL or DLradio link failure.

A WTRU may disable a dormant mode on a condition that the WTRU hasreceived control signaling (e.g., for scheduling of dedicatedtransmissions) for a consecutive number (which may be configurable) ofDRX cycles, or the WTRU receives a MAC DRX CE indicating that adifferent (e.g. possibly shorter) DRX cycle may be used. The WTRU mayreceive signaling (e.g., a MAC CE) that indicates an index to a DRXconfiguration from a list of available DRX configurations.Alternatively, the WTRU may revert back to a default DRX configuration.For example, the WTRU may revert back to a default configuration forother configuration aspects such as a RACH configuration and/or a PUCCHconfiguration (e.g., for D-SR).

A WTRU may disable a dormant mode on a condition that the WTRU has beenscheduled during a specific set of subframes and/or for a period longerthan a certain number of subframes, or the WTRU determines that thePDCCH activity is above a certain threshold (which may be configurable).

A WTRU may disable a dormant mode based on a timer. For example, theWTRU may disable a dormant mode on a condition that a certain number ofsubframe(s) have elapsed. The timer may be restarted based on the WTRU'sbuffer state. For example, the timer may be restarted on a conditionthat the uplink buffer of the WTRU are non-zero, for example, for asubset of the WTRU's configured LCGs and/or LCHs. The WTRU may determinethat buffer levels are above the available uplink resources for acertain amount of time which may lead to disabling dormancy such thatmore resources may be requested.

The WTRU may disable a dormant mode on a condition that it receives aTAC and has valid uplink timing alignment (e.g., if the TAT is startedat least for the primary serving cell of the WTRU's configuration), forexample, following a transmission on a PRACH or on a contention-basedresource.

The WTRU may disable a dormant mode on a condition that an RRCreconfiguration procedure is performed that adds to the WTRU'sconfiguration at least one DRB which is not an XRB.

The WTRU may disable a dormant mode on a condition that the WTRU has newdata available for transmission. For example, the WTRU may disable adormant mode on a condition that the WTRU determine that data which maybenefit from a connected mode behavior becomes available fortransmission (e.g., a radio bearer (i.e., a DRB and/or a SRB) that isnot configured as an XRB needs to be set up, or data for an existing DRBand/or SRB that is not an XRB becomes available for transmission).

The WTRU may disable a dormant mode on a condition that data becomesavailable for transmission on an SRB and/or any DRB that is notconfigured as an XRB. The WTRU may disable a dormant mode on a conditionthat a scheduling request (SR) is triggered (or pending) or a BSR hasbeen triggered thereof. The WTRU may disable a dormant mode on acondition that an SR is triggered and/or is pending for an SRB, that anSR is triggered and/or is pending for a DRB that is not configured as anXRB, that an SR is triggered and/or is pending for an RB associated withan LCH/LCG with a higher priority than a threshold, and/or that a higherlayer (e.g., NAS) initiates the setup of a new service which requires atransition to a connected mode (e.g., RRC_CONNECTED state withoutdormancy behavior). The WTRU may then initiate an RRC connection requestprocedure.

Alternatively, the WTRU may disable a dormant mode on a condition thatthe data arrival rate for at least a subset of DRBs is above a certainthreshold (which may be configurable), the inter-packet arrival rate fora specific DRB (e.g., for XRB(s) and when other DRBs have empty buffersduring that time) is below a certain threshold (which may beconfigurable), or the total sum of data is above a certain threshold.

The WTRU may disable a dormant mode on a condition that a configuredmeasurement event triggers a measurement report, for example, for ameasurement event of a specific type (e.g., serving cell below athreshold or explicitly indicated in the measurement configuration).

The WTRU may disable a dormant mode on a condition that the WTRUreceives an RRC connection reconfiguration message with the mobilitycontrol IE not indicating that the WTRU needs to remain in a dormantmode, or if the handover is for a different radio access technology(RAT) or to a different public land mobile network (PLMN), or if afailure to perform a handover occurs while trying to continue in adormant state.

The WTRU may disable a dormant mode on a condition that the cellreselection procedure results in selection of a cell different than thecell that the WTRU is currently connected to, or is camping on.

The WTRU may disable a dormant mode on a condition that the WTRUexperiences radio link problems (e.g., out-of-synch or radio linkfailure condition is met), or that the WTRU performs the RRC connectionre-establishment procedure.

The WTRU may disable a dormant mode on a condition that the time elapsedbetween uplink and/or downlink transmissions (e.g., inter-packetinter-burst arrival time) is below a certain threshold (which may beconfigurable). The WTRU may perform such measurements for one or moresubsets of the configured DRBs. For example, the WTRU may keep track ofinter-packet or inter-burst arrival times for a set of DRBs configuredas XRBs. The WTRU may maintain an average time estimate. The WTRU's timeestimates may be reset on a condition that transmissions for SRBs areperformed, that transmissions for any RB that is not configured as anXRB is performed, and/or that the WTRU exits a dormant mode.

The WTRU may disable a dormant mode on a condition that the buffer fillrate for uplink and/or downlink transmissions is above a certainthreshold (which may be configurable) over a certain period. The WTRUmay perform such measurements for one or more subset of the configuredDRBs. For example, the WTRU may keep track of buffer fill rate for DRBsconfigured as XRBs. The WTRU's buffer fill rate estimates may be reseton a condition that transmissions for SRBs are performed, thattransmissions for any RB that is not configured as an XRB are performed,and/or that the WTRU exits a dormant mode.

The WTRU may enable and disable a dormant mode using any combination ofthe above embodiments on a condition that the use of a dormant mode hasbeen configured and/or allowed in the radio resource configuration ofthe WTRU. The configuration for dormant mode may be in addition to theconfiguration used while not operating with the dormant mode for aspectssuch as DRX, PUCCH, SRS and PRACH. The configuration may include, foreach aspect, a plurality of parameters, for example, structured as anindexed list of parameters.

A WTRU in connected mode may enable a dormant mode of operation based onan explicit indication in accordance with at least one of the followingembodiments.

The WTRU may transit to a dormant mode on a condition that the NAS ofthe WTRU transmits control signaling (e.g., a NAS service request or aNAS service update) that indicates a request for dormant mode operation.For example, the WTRU may transit to a dormant mode when the NAS of theWTRU receives control signaling that indicates dormant mode operation.

The WTRU may enable a dormant mode on a condition that it receives anRRC message indicating that a dormant mode needs to be enabled. Forexample, the WTRU may enable a dormant mode on a condition of receipt ofan RRC connection reconfiguration message with an indication that thedormant mode needs to be enabled, (e.g., a message including a flagand/or triggering a state transition to a different RRC state, such asRRC_DORMANT or a sub-state of an RRC idle or connected state thatsupports dormant behavior). The message may include an index to a set ofconfiguration parameters to use while operating with the dormant mode.The WTRU may confirm the request and/or the reconfiguration in aresponse message.

Alternatively, the WTRU may enable a dormant mode on a condition thatthe WTRU receives an RRC connection release message. This message mayinclude an indication that the dormant mode needs to be enabled, (e.g.,a message including a flag and/or triggering a state transition to adifferent RRC state, such as RRC_DORMANT or a sub-state of the RRC idleor connected state that supports dormant behavior). The WTRU may confirmthe request and/or the reconfiguration in a response message. The WTRUmay include additional information in the confirmation, includingtraffic characteristics such as at least one of average inter-packetarrival time with or without mean deviation, average inter-burst arrivaltime with or without mean deviation, average burst size, buffer fillrate, average packet size, or the like. The WTRU may include informationrelated to the WTRU's mobility. The WTRU may include a selection ofpreferred parameters such as DRX parameters and/or scheduling requestparameters, for example, an index corresponding to parameters selectedfrom a list of available parameters. The message that enables a dormantmode may remove and/or release configured DRB(s) and/or SRB(s), and mayadd, reconfigure, or maintain an XRB(s).

The WTRU may enable a dormant mode on a condition that it receives L2control signaling that indicates that a dormant mode needs to beenabled. For example, the WTRU may enable a dormant mode on a conditionthat that WTRU receives a MAC CE with an indication that a different(e.g., longer) DRX cycle needs to be used. The WTRU may receivesignaling (e.g., a MAC CE) that indicates an index to a DRXconfiguration from a list of available DRX configurations. For example,the indication may correspond to a different (e.g., non-default)configuration for other configuration aspects such as a RACHconfiguration and/or a PUCCH configuration, (e.g., for D-SR). Thesignaling may include a dedicated preamble index (e.g.,ra-Preamblelndex) and/or a PRACH mask (e.g., a ra-PRACH-MaskIndex).Alternatively, the WTRU may enable a dormant mode on a condition thatthe WTRU receives a MAC deactivation CE that deactivates secondaryserving cells of the WTRU, and indicate that the dormant mode needs tobe used for the primary serving cell. Alternatively, the WTRU may enablea dormant mode on a condition that the WTRU receives a MAC deactivationCE that deactivates the primary serving cell of the WTRU, (for example,for a number of subframes that may be indicated in the MAC CE,configured by RRC, or known a priori).

The WTRU may enable a dormant mode on a condition that it receives L1control signaling that indicates a downlink assignment for a PDSCHtransmission and/or an uplink grant for a PUSCH transmission. Forexample, the WTRU may enable a dormant mode on a condition that controlsignaling is received within a specific subframe (e.g., within asemi-static configured set of subframes and/or within the on-duration ofthe DRX active time). Alternatively, the WTRU may enable a dormant modeon a condition that the L1 control signaling is received in a subframethat is part of the DRX active time but not part of the WTRU's DRXon-duration. Alternatively, the WTRU may enable a dormant mode on acondition that it receives L1 control signaling indicating that the WTRUneeds to enable a dormant mode, (e.g., using a bit within the DCIformat). Alternatively, the WTRU may enable a dormant mode on acondition that the DCI is scrambled using a WTRU-specific RNTIindicating that the WTRU needs to change the state of the dormant modeoperation.

The WTRU may enable a dormant mode based on traffic detection function(TDF)-based control plane (CP) policing, (e.g., using conventional TDFenforcing operator policies which are either provided through the policycontrol rules function (PCRF) or configured by the operator directly inthe PGW (i.e., policy control and enforcement function (PCEF)). TheTDF/application detection and control function (ACDF) identifies userplane flows that exhibit certain behavior and feeds this informationback to the control plane management entities. An example of thebehavior includes, but is not limited to, the reception of bursts ofsmall size packets at regular intervals that may cause the establishmentor tear down of system resources. Since the detection of such behaviorin the user plane may be linked or associated to the control planedisturbances, the PGW (through the SGW) may classify such behavior andcommunicate its characteristics to the MME (or other control planeentity). The MME may then take an action or pass this information to theeNB or to the WTRU that may then take specific actions. Examples of suchspecific actions include, but are not limited to, instantiating a newbearer to flush out certain traffic or back off specific control planeevents such as an NAS service request.

A WTRU may disable a dormant mode of operation based on an explicitindication in accordance with at least one of the following embodiments.

The WTRU may transit away from a dormant mode on a condition that theNAS of the WTRU transmits control signaling (e.g., a NAS service requestor a NAS service update) that indicates an operation not related to adormant mode, (e.g., resources for transmissions in a connected mode).Alternatively, the WTRU may transit from a dormant mode on a conditionthat the NAS of the WTRU receives control signaling that indicates anoperation not related to a dormant mode (e.g., resources fortransmissions in a connected mode).

The WTRU may disable a dormant mode when it receives an RRC messageindicating that a dormant mode needs to be disabled. For example, theWTRU may disable a dormant mode on a condition that the WTRU receives anRRC connection reconfiguration message with an indication that thedormant mode needs to be disabled, (e.g., a message including a flagindicating and/or triggering a state transition to a different RRCstate, such as RRC_CONNECTED or RRC_IDLE without supporting the dormantbehavior).

The WTRU may transit from the dormant mode to a connected state on acondition that the WTRU receives an RRC message which reconfigures theRRC connection, such as an RRC connection reconfiguration request. TheRRC connection reconfiguration message may indicate that the dormantbehavior needs to be deactivated.

The WTRU may transit from the dormant mode to an idle state on acondition that the WTRU receives an RRC connection release message. TheRRC connection release message may include an indication that thedormant mode needs to be disabled, (e.g., a message including a flagindicating that the dormant behavior needs to be deactivated and/or thattriggers a state transition to an idle mode, such as RRC_IDLE). The WTRUmay confirm the request and/or the reconfiguration in a responsemessage. The messages that disable a dormant mode may remove and/orrelease any configured radio bearers (e.g., any SRB, DRB, and/or XRB).

The WTRU may disable a dormant mode on a condition that it receives L2control signaling indicating that a dormant mode needs to be disabled.For example, the L2 control signaling may be a MAC CE with an indicationthat a different (e.g., shorter) DRX cycle needs to be used, or a MACactivation CE that activates at least one serving cell of the WTRU,e.g., a secondary cell of the WTRU's configuration. The WTRU may receivesignaling (e.g., a MAC CE) that indicates an index to a DRXconfiguration from a list of available DRX configurations.Alternatively, the WTRU may revert back to a default DRX configuration.For example, the WTRU may revert back to a default configuration forother configuration aspects such as a RACH configuration and/or a PUCCHconfiguration (e.g., for D-SR).

The WTRU may disable a dormant mode on a condition that it receives L1control signaling that indicates a downlink assignment for a PDSCHtransmission and/or an uplink grant for a PUSCH transmission. Forexample, the WTRU may disable a dormant mode on a condition that thecontrol signaling is received within a specific subframe, such as withina semi-statically configured set of subframes and/or within theon-duration of the DRX active time for multiple consecutive DRX cycles.Alternatively, the WTRU may disable a dormant mode on a condition thatit receives L1 control signaling that explicitly indicates that the WTRUneeds to disable a dormant mode, for example, using a bit within the DCIformat. Alternatively, the WTRU may disable a dormant mode on acondition that the DCI is scrambled using a WTRU-specific RNTIindicating that the WTRU needs to change the state of the dormant modeoperation. Alternatively, the WTRU may disable a dormant mode on acondition that the WTRU receives PDCCH signaling that triggers a randomaccess procedure.

Embodiments for deriving scheduling occasions for a WTRU in a dormantmode are explained hereafter.

The WTRU may determine a sequence of one or more subframes for which itmay enable reception of control signaling including receiving a PDCCHand decoding for DCIs scrambled with a specific RNTI. In addition, theWTRU may buffer at least part of the corresponding PDSCH such that if aDCI addressed to the WTRU's RNTI, the WTRU may then decode thecorresponding transmission on the PDSCH, if needed.

For any of the embodiments described herein, the WTRU may enable and/ordisable the reception of control signaling after a fixed number ofsubframes (e.g. 4 ms or 8 ms), or any period that may correspond to theWTRU processing time.

In addition, the periods during which the WTRU in a dormant modemonitors control signaling may be used to control other behavior of theWTRU. For example, a WTRU may perform channel measurements (ifconfigured), report channel quality indicator (CQI), precoding matrixindicator (PMI), and/or rank indicator (RI) (if configured), transmit asounding reference signal (SRS) (if configured) in subframes for whichit actively monitors a PDCCH, or when it monitors a PDCCH for aWTRU-specific RNTI (e.g., the WTRU's C-RNTI).

In order to allow an eNB to maintain a WTRU time-aligned, the WTRU maytransmit an SRS in subframes for which it monitors control signaling.Alternatively, the WTRU may transmit an SRS in a special subframe, whichwill be explained in detail below, when not having proper timingalignment, in response to the aperiodic SRS request, and/or while theWTRU is monitoring downlink control signaling.

The WTRU may use a DRX mechanism in the dormant mode of operation, forexample, to reduce power consumption. The DRX mechanism provides anoccasion during which a WTRU may monitor control signaling on, forexample, a PDCCH. The DRX mechanism may be a layer 3 (e.g., RRC)mechanism, or alternatively a layer 2 (e.g., MAC) mechanism used inRRC_CONNECTED mode, or a modified mechanism thereof.

The WTRU may enable or disable reception of downlink control signalingfor downlink assignments, uplink grants, and DCIs for PDCCH-order toperform the random access procedure independently. For example, if theWTRU has no data available for uplink transmissions but determines thatit needs to monitor control signaling in a concerned subframe, it mayattempt decoding of control signaling for downlink assignments and forPDCCH-order to perform the random access procedure.

A WTRU in a dormant mode may implicitly enable reception of controlsignaling for scheduling of unicast transmission(s) using at a least oneof the following embodiments.

The WTRU may use a layer 3 (L3) DRX mechanism. The WTRU may enablereception of control signaling on a PDCCH and decode for one or moreDCI(s) scrambled with an RNTI assigned to the WTRU at the WTRU-specificpaging occasion. The RNTI may be a WTRU-specific RNTI (e.g., the WTRU'sC-RNTI). The RNTI may be used in decoding attempts on the PDCCH inaddition to other RNTIs for which the WTRU may decode at the pagingoccasion, (e.g., P-RNTI). The WTRU may monitor a PDCCH for its C-RNTI onthe WTRU-specific paging occasions as for idle mode procedures. Thepaging occasion may be extended by a number of subframes (which may beconfigurable) for which the WTRU may monitor for the assigned RNTI(e.g., the WTRU's C-RNTI).

Alternatively, the WTRU may use an L3 (e.g., RRC) configured occasionthat may differ from the WTRU-specific paging occasion. For example, theWTRU may monitor a PDCCH for its C-RNTI on a scheduling occasion. Onescheduling frame may correspond to one radio frame, which may containone or more scheduling occasions. The scheduling frame and thescheduling occasion may be derived using a combination of a formula andDRX parameters provided by RRC (either by broadcasting or usingdedicated signaling). For example, the scheduling frame may bedetermined by a function of the system frame number (SFN) and anidentity of the WTRU (e.g., derived from the WTRU's international mobilesubscriber identity (IMSI)), while the scheduling occasion may bedetermined based on an index to a subframe pattern which may be afunction of an identity of the WTRU (e.g., derived from the WTRU'sIMSI).

Alternatively, the scheduling frame and the scheduling occasion may bereceived via dedicated signaling (e.g., RRC), for example, as part of aradio resource configuration procedure or a signaling procedure forconfiguring DRX for the WTRU. The WTRU follows a DRX cycle, and thecycle corresponds to the individual time interval between monitoringscheduling occasions for a specific WTRU. The WTRU may monitor at leastone scheduling occasion per DRX cycle.

Alternatively, the WTRU may use a layer 2 (L2) DRX mechanism. The WTRUmay be configured with, or may autonomously derive, one or more DRXconfigurations for L2 DRX operation. For example, the WTRU may use amultiple of the configured layer 2 DRX cycle and/or may be configuredwith an additional DRX cycle. For example, the WTRU may enable receptionof control signaling on a PDCCH and decode for one or more DCI(s)scrambled with an RNTI assigned to the WTRU from the subframe at which ascheduling request is triggered. The RNTI may be a WTRU-specific RNTI(e.g., the WTRU's C-RNTI). The WTRU may monitor a PDCCH for its C-RNTIfor subframes during which a scheduling request (SR) is pending. The SRmay be triggered (and/or is pending) for an SRB, (e.g., when new databecomes available for the SRB). The SR may be triggered (and/or ispending) for a DRB, (e.g., when new data becomes available for the DRB).The SR may be triggered for a DRB that is not configured as an XRB. TheSR may be triggered (and/or is pending) for an RB associated to anLCH/LCG with a higher priority than a threshold, (e.g., when new databecomes available for the DRB). The SR may be triggered (and/or ispending) from the availability of transmission of an L3 message (e.g.,measurement report), for example, of a specific type, such as servingcell below threshold.

Alternatively, the WTRU may enable reception of control signaling on aPDCCH in a subframe subsequent to the transmission of a random accesspreamble on a PRACH resource. The WTRU may decode for an RA-RNTI for arandom access response and for a C-RNTI, if a dedicated preamble is usedfor the RACH.

For any of the above, once the WTRU successfully decodes at least onecontrol signaling, the PDCCH monitoring activity may be extended,including the cases where a DCI is received including schedulinginformation, (for example, if a DCI is decoded that requests anaperiodic SRS transmission for the purpose of providing a “keep-alive”and/or for timing alignment purposes at the eNB, or if a DCI is decodedthat triggers the random access procedure).

A WTRU in a dormant mode may implicitly disable reception of controlsignaling for scheduling of unicast transmissions. For example, on acondition that the WTRU successfully decodes a DCI, it may extend thePDCCH monitoring activity for a number of subsequent subframes, (e.g.,based on a timer which may be restarted upon successful decoding ofcontrol signaling and/or using an L2 DRX if configured), until therelevant timer(s) expires such that the WTRU may disable reception ofcontrol signaling at least until the next wake-up occasion.

A WTRU in a dormant mode may enable reception of control signaling forscheduling of unicast transmission(s) based on explicit signaling.

The WTRU may be configured with wake-up occasions that occur at periodicintervals. Alternatively, the WTRU may enable reception of controlsignaling on a PDCCH and decode for one or more DCI(s) scrambled with anRNTI assigned to the WTRU (e.g., a C-RNTI) after reception of a pagingmessage that includes at least one paging record with an identifier ofthe WTRU (e.g., a WTRU identity in the paging record that matches one ofthe WTRU identities allocated by upper layers or by RRC). The pagingmessage may include dedicated information for the WTRU, such as a C-RNTIand/or a (dedicated) preamble and/or a (dedicated) PRACH resource.

The WTRU may initiate the random access procedure following thereception of the paging message. The random access procedure may beperformed on a condition that the WTRU has no valid timing alignment, orthe WTRU has no configuration for a transmission on a PUSCH withoutfirst having a valid timing alignment (e.g., if the WTRU is not allowedto transmit on a PUSCH without time alignment in the uplink).

For any of the above, once the WTRU successfully decodes at least onecontrol signal, the PDCCH monitoring activity may be extended. Forexample, it may be the case where a DCI received includes schedulinginformation, for example, if a DCI is decoded that requests an aperiodicSRS transmission (e.g., for the purpose of providing a “keep-alive”and/or for timing alignment purposes at the eNB).

A WTRU in a dormant mode may disable reception of control signaling forscheduling of unicast transmission(s) based on explicit signaling. Theexplicit signaling includes L3 signaling (e.g., RRC), L2 signaling(e.g., MAC CE), and L1 signaling (e.g., DCI with explicit indication).For example, the WTRU may disable reception of control signaling uponreception of a MAC DRX CE indicating that the WTRU may stop monitoring aPDCCH. Alternatively, a specific MAC CE may be defined for this purpose.For example, the WTRU may disable reception of control signaling uponreceipt of a DCI that includes an indication that the WTRU may disablereception of control signaling, or alternatively a DCI scrambled with aspecific RNTI.

Embodiments for downlink and/or uplink data transmissions in a dormantmode are disclosed hereafter. The traffic pattern for intermittenttransmissions of small data may be characterized by downlink datatransfer only (e.g. a “keep-alive”-type of message from a networkservice), downlink data transfer followed by an uplink data transfer(e.g., request-response type of messages, such as a request originatingfrom a network service (e.g., a location-based service and/or apush-based service (e.g., email)), uplink data transfer only (e.g., akeep-alive type of message from an application), and uplink datatransfer followed by a downlink data transfer (e.g., request-responsetype of messages, such as a request originating from an application in amobile terminal (e.g., a location-based client and/or a fetch-basedservice (e.g., an email client)).

A WTRU in a dormant mode may monitor control signaling according to oneor more embodiments disclosed herein to determine scheduling occasions.While in a dormant mode, the WTRU may use the connectionless approach orcontrol plane/signaling bearers to transfer small data. A WTRU mayperform any of the following procedures for each corresponding datatransfer when initiated.

A WTRU may be scheduled for an uplink transmission while the WTRU maynot have proper timing alignment, (e.g., when the TA timer expired forthe WTRU).

In one embodiment, a WTRU may be configured for uplink transmissions ina special subframe that may tolerate a timing misalignment. The specialsubframe may include at least one guard period, (e.g., a number ofsymbols sufficiently large that may be based on the size of the cell)such that even a large timing misalignment would not interfere withother intra-cell transmissions in adjacent subframes. For example, oneguard period may be defined at the beginning and/or at the end of asubframe. The WTRU may perform an unsynchronized transmission, (e.g., arandom access procedure including a RACH preamble transmission on aPRACH resource, a PUCCH or PUSCH transmission), in the special subframe.The random access in the special subframe may be contention-free.

The WTRU may receive dedicated signaling (e.g., RRC) that configures ina semi-static manner (e.g. periodic in time) one or more specialsubframes. Alternatively, the WTRU may receive dynamic PDCCH controlsignaling (e.g., DCI for a grant for a PUSCH transmission).Alternatively, the WTRU may receive broadcast signaling (e.g., systeminformation broadcast on a broadcast control channel (BCCH)) thatindicates one or more special subframes and/or a periodicity. Thenetwork may handle any possible intra-cell and inter-cell interferencethrough appropriate allocation of uplink resources. For example, suchsubframe may be a recurrent subframe (e.g., subframe 1 of each integer Xnumber of radio frames, where X may be 1 or larger).

Other WTRUs may not be allowed to transmit in the special subframe. Theformat of the special subframe may be understood by a WTRU(s) supportingtransmissions in the special subframe. For the WTRUs that do not supporttransmissions in the special subframe, the special subframe may beconfigured as a multicast/broadcast over a single frequency network(MBSFN) subframe. This would ensure backward compatibility for thenon-supporting WTRUs, while preventing intra-cell and inter-cellinterference within the special subframe.

A WTRU that does not have proper timing alignment may perform an uplinktransmissions on a PUSCH resource in the special subframe according toPDCCH control signaling, but may not perform PUSCH transmission on othersubframes. The special subframe may not be constrained to PUSCH or PRACHtransmissions, but may apply to SRS transmissions (if configured) or anyother physical channel transmissions. This will be referred to as an“uplink transmission in the special subframe.”

For special subframes, the WTRU may be configured with at least one ofthe following: parameters for decoding and processing of dynamicdownlink control signaling that schedules uplink transmissions on acontention-based PUSCH (CB-PUSCH) resource including, for example, aspecific RNTI to monitor on the PDCCH (e.g. a CB-RNTI), a subframe inwhich the WTRU may decode the control signaling for CB-PUSCHtransmissions, a subframe in which the WTRU may perform a transmissionon a CB-PUSCH resource, or the like. The configuration may be similar toSPS configuration with respect to the periodicity of the resources,parameters such as RNTI, resource allocation (e.g., resource blocks) andmodulation and coding scheme (MSC).

The WTRU may periodically monitor and decode DCIs scrambled with aCB-RNTI on a PDCCH to determine the parameters to perform an uplinktransmission. The WTRU may decode the control signaling on at least oneof the conditions that it has data available for transmission, the datacorresponds to an XRB, or the WTRU has a buffer status report (BSR) totransmit (e.g., for data from any RBs including an SRB), or the WTRU hasvalid uplink timing synchronization.

A WTRU may receive dedicated PRACH resources valid for the WTRU-specificsubframe(s). For the WTRU-specific subframes, the WTRU may be configuredwith at least one of the following: dedicated parameters fortransmissions on a PRACH resource, a dedicated preamble(ra-PreambleIndex), a PRACH mask index (PRACH-Mask-index), a maximumnumber of preamble retransmissions, or the like. For example, the WTRUmay be configured with a dedicated preamble (e.g., for a contention-freetransmission on the PRACH resource) and/or with a dedicated PRACHresource (e.g., for multiplexing different WTRUs for a given subframe).The WTRU may perform a transmission on a PRACH using the configurationin a subset of subframes. This subset of subframe may be configured bythe network, for example, using a periodicity, a bit mask applicable toa plurality of subframes (e.g., a frame, or a multiple thereof), and/ora function of a system frame number (SFN). This procedure will bereferred to as a “CFRA transmission in a WTRU-specific subframe.”

The WTRU may be configured with multiple sets of PRACH parameters toconvey additional information to the network. Such information mayinclude HARQ feedback, a request for uplink resources includingresources for XRB(s) and/or resources for radio bearers other than XRBs(e.g., with higher priority). The parameters that may be configured toconvey such information include separate sets of PRACH resources,different sets of WTRU-specific subframes for PRACH, and/or differentset of dedicated preambles. For example, when the WTRU performs apreamble transmission in the WTRU-specific PRACH occasion for thepurpose of requesting uplink resources, the WTRU may select either afirst dedicated preamble to indicate scheduling request (i.e.,scheduling request via random access procedure (RA-SR)) for any type ofdata in the WTRU's buffer (including a BSR) or a second preamble toindicate SR for data corresponding to XRBs. Alternatively, a firstpreamble may indicate SR for XRBs (for uplink transmissions of user datawhile remaining in dormant mode) and a second preamble for SRBs (e.g.,to request a RRC connection that exits the dormant behavior).Alternatively, for the previous example above, instead of selectingbetween a first and a second preamble, the WTRU may instead selectbetween a first and a second WTRU-specific subframe. Alternatively, theWTRU may select between a first and a second PRACH resource.Alternatively, the WTRU may select between a first configuration forscheduling request such as a PRACH configuration and a secondconfiguration for scheduling request such as a PUCCH configuration forD-SR, on the condition that the WTRU has valid uplink timing alignment.

The WTRU may perform a preamble transmission in the WTRU-specific PRACHoccasion (i.e., in the WTRU-specific subframe) for sending HARQ feedbackcorresponding to one or a plurality (e.g., a burst) of transmissions orretransmissions, for example, for XRBs. The WTRU may select a firstpreamble such that it corresponds to a HARQ acknowledgement, or toacknowledge the entire burst. The WTRU may select a second preamble toperform RA-SR and/or to indicate a HARQ NACK. An RLC report may beincluded in the first uplink transmission which allows the network todetermine whether or not to perform the retransmission at the RLC.Alternatively, instead of selecting between first and second preambles,the WTRU may instead select between first and second WTRU-specificsubframes. Alternatively, the WTRU may select between first and secondPRACH resources. Alternatively, the WTRU may select the preamble used toindicate HARQ feedback (e.g., a HARQ ACK) as a function of the firstControl Channel Element (CCE) of the DCI received on the PDCCHsignaling, which DCI scheduled the downlink transmission for which HARQfeedback is transmitted. In case the feedback corresponds to a pluralityof transmissions (e.g., a burst), the preamble selected may be afunction of the DCI that scheduled the last transmission in the burst.In case the feedback corresponds to a plurality of transmissions (e.g.,a burst), the HARQ feedback may be an ACK on a condition that alldownlink transmissions of the bundle have been successfully received.Alternatively, a preamble may be transmitted on a condition that atleast one transmission in a burst was successfully received. Thepreamble selected may be a function of the number of transmissionsuccessfully received in the burst, for example, for consecutivetransmissions starting from the last transmission for which a positiveacknowledgement has not been sent.

Alternatively, a WTRU in a dormant mode may use a conventional procedureto access the network in subframes other than the WTRU-specificsubframe, for example, for data other than data associated to an XRB(that may exclude a BSR). For example, the WTRU may use a random accessprocedure using cell parameters or other dedicated parameters that maynot correspond to those associated to a PRACH transmission for theWTRU-specific subframe, or use a scheduling request on a PUCCH ifconfigured on a condition that the WTRU has valid uplinksynchronization, for example, to establish an RRC connection and/or torequest dedicated transmission resources when data for which the dormantbehavior is not suitable becomes available for transmission. Such datamay correspond to data with a higher priority (e.g., SRB data, DRBdata). Such data may correspond to data for any radio bearer that is notan XRB of the WTRU's configuration. Alternatively, if the WTRU receivescontrol signaling on a PDCCH that requests the WTRU to perform therandom access procedure, the WTRU may perform the conventional randomaccess procedure.

The WTRU operating in a dormant mode may initiate a procedure to gainvalid uplink timing alignment (e.g., random access including a CFRAtransmission in a WTRU-specific subframe, or SRS transmission in thespecial subframe if configured) if the WTRU does not have a valid uplinktiming alignment, (e.g., a TAT is not running at least for the primaryserving cell). The WTRU may be configured (e.g., by upper layers) togain timing alignment on a condition that the WTRU in a dormant modereceives successful downlink control signaling indicating a PDSCHassignment (such that the WTRU may subsequently transmit HARQ A/N on aPUCCH), or downlink control signaling indicating a PUSCH grant (suchthat the WTRU may subsequently transmit on a PUSCH). The WTRU may notperform the transmission on the PUSCH for the grant if the WTRU does nothave a valid timing alignment in the concerned subframe.

The WTRU operating in a dormant mode may initiate a procedure to gainvalid uplink timing alignment on a condition that the WTRU has dataavailable for transmission in its buffer (e.g., a BSR has beentriggered), or the WTRU has a pending scheduling request, or if the WTRUdetermines that it needs to obtain a valid timing alignment while in adormant mode, (e.g., to initiate a random access procedure).

For downlink data transfer, a WTRU operating in a dormant mode mayreceive and decode dedicated downlink assignment(s) on a PDCCH (e.g.,scrambled using a C-RNTI), whether or not the WTRU has a valid timealignment (TA). In case the WTRU has a valid TA, the WTRU may transmitHARQ A/N feedback (e.g., on a PUCCH). Otherwise, the WTRU may nottransmit any HARQ A/N feedback. Alternatively, the WTRU may perform aCFRA transmission in a WTRU-specific subframe to gain uplink timingsynchronization and/or to acknowledge the downlink transmission.

For downlink data transfer followed by uplink data transfer, a WTRUoperating in a dormant mode may receive and decode dedicated downlinkassignment(s) on a PDCCH (e.g., scrambled using C-RNTI), whether or notthe WTRU has a valid TA. In case the WTRU has a valid TA, the WTRU maytransmit HARQ A/N feedback (e.g., on a PUCCH) after receiving thedownlink transmission. Alternatively, the WTRU operating in a dormantmode may receive and decode control signaling on a PDCCH (e.g.,scrambled using a C-RNTI) that orders the WTRU to perform a randomaccess procedure, in particular, if the WTRU does not have a valid TA.The WTRU may receive and decode control signaling (e.g., an uplinkgrant) on a PDCCH (e.g., scrambled using C-RNTI) for an uplinktransmission on a dedicated PUSCH resource, if the WTRU has a valid TA.Alternatively, the WTRU may transmit on a dedicated PUSCH resource usingthe special subframe, if the timing of the grant corresponds to thespecial subframe and if the WTRU does not have a valid timing alignment.The WTRU may receive and decode control signaling (e.g., an uplinkgrant) on a PDCCH (e.g., scrambled using a contention based RNTI(CB-RNTI)) for a contention-based uplink transmission on a PUSCH. TheWTRU may transmit on a PUSCH resource in case the WTRU has a valid TA.The WTRU may transmit on a PUSCH resource in the special subframe, ifthe WTRU does not have a valid timing alignment and/or if the timing ofthe grant corresponds to the special subframe.

The WTRU may initiate the scheduling request (SR) procedure either usinga valid PUCCH resource, using a CFRA transmission in a WTRU-specificsubframe if configured, or using a random access procedure. The WTRU mayinitiate the SR procedure on a condition that no contention-based grantis available for the concerned subframe. For example, the PUCCH resourcefor D-SR may be a resource configured for use while in a dormant mode.Alternatively, the method and/or the resource to use for the SR may besignaled in a downlink transmission such as in a MAC CE.

For uplink data transfer, a WTRU operating in a dormant mode mayinitiate the SR procedure either using a valid PUCCH resource for SR,using a CFRA transmission in a WTRU-specific subframe if configured, orusing a random access procedure. The WTRU may initiate the SR procedureon a condition that no contention-based grant is available for theconcerned subframe.

The WTRU may receive and decode control signaling (e.g., an uplinkgrant) on a PDCCH (e.g., scrambled using C-RNTI) for an uplinktransmission. The WTRU may transmit on a dedicated PUSCH resource on acondition that the WTRU have a valid TA. Alternatively, the WTRU maytransmit on a dedicated PUSCH resource in the special subframe, if thetiming of the grant corresponds to the special subframe and if the WTRUdoes not have a valid timing alignment.

The WTRU may receive and decode control signaling (e.g., an uplinkgrant) on a PDCCH (e.g., scrambled using a CB-RNTI) for acontention-based uplink transmission on a PUSCH. In this case, the WTRUmay transmit on a PUSCH resource if the WTRU has a valid TA, or on aPUSCH resource in the special subframe on a condition that the WTRU doesnot have a valid timing alignment and/or the timing of the grantcorresponds to the special subframe.

For uplink data transfer followed by downlink data transfer, a WTRUoperating in a dormant mode may initiate the SR procedure either using avalid PUCCH resource for SR, using a CFRA transmission in aWTRU-specific subframe, or using a random access procedure. The WTRU mayinitiate the SR procedure on a condition that no contention-based grantis available for the concerned subframe.

The WTRU may receive and decode control signaling (e.g., an uplinkgrant) on a PDCCH (e.g., scrambled using C-RNTI) for an uplinktransmission. The WTRU may transmit on a dedicated PUSCH resource on acondition that the WTRU has a valid TA, or on a dedicated PUSCHresources in the special subframe, if the timing of the grantcorresponds to the special subframe and if the WTRU does not have avalid timing alignment.

The WTRU may receive and decode control signaling (e.g., an uplinkgrant) on a PDCCH (e.g., scrambled using a CB-RNTI) for acontention-based uplink transmission on a PUSCH. In this case, the WTRUmay transmit on a PUSCH resource if the WTRU has a valid TA, or on aPUSCH resource in the special subframe on a condition that the WTRU doesnot have a valid timing alignment and/or the timing of the grantcorresponds to the special subframe.

In addition, the WTRU may receive and decode dedicated downlinkassignment(s) on a PDCCH (e.g., scrambled using a C-RNTI), whether ornot the WTRU has valid time alignment. In case the WTRU has a valid TA,the WTRU may transmit HARQ A/N feedback (e.g., on a PUCCH).

Embodiments for channel quality measurements and reporting in a dormantmode are disclosed hereafter. A WTRU operating in a dormant mode may beconfigured with channel state information reporting, such as channelquality indicator (CQI), precoding matrix indicator (PMI), rankindicator (RI), or the like. The WTRU may maintain the CQI configurationwhen it has no valid timing alignment. For example, the WTRU may notapply the default physical channel configuration for CQI-ReportConfigand cqi-Mask upon TAT expiry.

The WTRU may measure and report channel state information, such as aCQI, a PMI, and/or an RI, for subframes for which it monitors controlsignaling on a PDCCH. The WTRU may measure and report starting from asubframe in which the WTRU successfully decodes control signaling. TheWTRU may measure and report a CQI, a PMI, and/or an RI in subframes forwhich it monitors control signaling on a PDCCH, for example, startingfrom a subframe in which the WTRU successfully decodes controlsignaling. The above may be applied to SRS configuration parameters(e.g., soundingRS-UL-ConfigDedicated) and procedures.

Embodiments for performing mobility-related procedures in a dormant modeare disclosed hereafter.

A WTRU operating in a dormant mode may support both network-controlledmobility (e.g., using configured L3 measurements) and WTRU-autonomousmobility (e.g., using cell reselection).

A WTRU operating in a dormant mode may perform cell reselection on acondition that no L3 measurements are configured, or during periods whenthe WTRU is not being actively scheduled by the network for unicasttransmissions.

A WTRU operating in a dormant mode may perform L3 measurements andmeasurement reporting with lower requirements in terms of measurementintervals compared to the RRC_CONNECTED state. The WTRU may perform L3measurements and reporting during periods when the WTRU is beingactively scheduled by the network for unicast transmissions. The WTRUmay release cell-specific WTRU-dedicated parameters when a mobilityevent occurs while the WTRU is in a dormant mode. For example, the WTRUmay release any dedicated configuration for random access, C-RNTI,configuration for scheduling occasions, DRX, and/or measurements, andthe like that may have remained valid while in a dormant mode. Suchmobility event includes, but is not limited to, reception of an RRCconnection reconfiguration message with a mobility control IE (handovercommand), the initiation of a cell (re)selection procedure, a cell(re)selection procedure that results in selection of a different cellthan the current serving cell, a traffic area update, a transition tothe RRC_IDLE mode, and/or stopping using the dormant behavior.

A WTRU operating in a dormant mode may be configured with L3measurements and, if configured, the WTRU may perform the measurementsduring period when it is actively being scheduled by the network forunicast transmissions. For example, a WTRU may, for a period of time,perform L3 measurements starting from the subframe in which it firstreceives control signaling for a downlink assignment and/or an uplinkgrant until, for example, a timer expires (e.g., the TA timer, or anyother activity timer) or until it stops monitoring the controlsignaling. The WTRU may report the measurements when triggered by anevent during a period when it is actively being scheduled by the networkfor unicast transmissions.

Embodiments for cell reselection and WTRU-controlled mobility aredisclosed hereafter. A WTRU operating in a dormant mode may perform cellreselection procedure according to idle mode procedures. The WTRU mayperform the cell reselection procedure if it has successfully receivedexplicit indication to start monitoring control signaling but has notsuccessfully decoded control signaling after a certain period of time.The WTRU may perform the initial connection establishment procedure inthe selected cell.

If the cell reselection procedure leads to the selection of a celldifferent than the one on which the WTRU operates, the WTRU may performat least one of the following. If the cell reselection occurs while theWTRU is being actively scheduled, the WTRU may move to idle mode andperform the initial connection establishment procedure in the selectedcell. If the cell reselection occurs while the WTRU is not beingactively scheduled, the WTRU may move to idle mode and camp on theselected cell. Alternatively, the WTRU may perform the initialconnection establishment procedure in the selected cell.

If the cell reselection occurs after the WTRU has successfully receivedexplicit indication to start monitoring control signaling but before theWTRU is first being actively scheduled, the WTRU may move to idle modeand perform the initial connection establishment procedure in theselected cell.

In any embodiments above, the WTRU may first attempt the connectionre-establishment procedure in the selected cell. If the WTRU isconfigured for measurement reporting and performs L3 measurements, theWTRU may not perform cell reselection procedure, for example, if theWTRU performs L3 measurements while the WTRU is being activelyscheduled.

Embodiments for configuring a radio bearer (XRB) for intermittentservices are disclosed hereafter. The WTRU may be configured with an XRBthat is associated with one or more evolved packet system (EPS) bearers.For example, a WTRU may be configured with one or more XRBs eachassociated to a value that corresponds to an EPS bearer, (e.g., aneps-BearerIdentity value). When the dormant mode is activated, the WTRUmay use the XRB for the transmission of user data (e.g., excludingcontrol plane data) corresponding to the concerned EPS bearer. One ormore EPS bearers may be associated to a given XRB.

In another embodiment, a WTRU may be configured with a single XRB. Thismay be the default behavior, or alternatively this may be indicatedusing either a flag or a fixed codepoint for the value of theeps-BearerIdentity. When the dormant behavior is activated, the WTRU mayuse the XRB for the transmission of any user data (e.g., excludingcontrol plane data) corresponding to any of the EPS bearers of theWTRU's configuration. This may apply to EPS bearers that are configuredwhen the WTRU initiates the use of a dormant behavior.

In another embodiment, the WTRU may be configured with one XRB for eachconfigured RB, e.g., there may be one XRB for each DRB of the WTRU'sconfiguration. For example, when the dormant behavior is activated, theWTRU may use the XRB for transmission of any user data (e.g., excludingcontrol plane data) corresponding to the associated RB (e.g., a DRB) ofthe WTRU's configuration.

In another embodiment, the WTRU may be configured with one XRB for eachdefault EPS bearer of the WTRU's configuration. When the dormantbehavior is activated, the WTRU may use the XRB for the transmission ofany user data (e.g., excluding control plane data) corresponding to theassociated EPS bearer of the WTRU's configuration. This may be appliedto bearers that are configured when the WTRU initiates the use of adormant behavior.

In another embodiment, the WTRU may be configured with a default XRB.When the dormant behavior is activated, the WTRU may use the default XRBfor the transmission of user data (e.g., excluding control plane data)corresponding to any EPS bearer that is not explicitly associated toanother XRB. This may be applied to EPS bearers that share a similarcontext (e.g., for applications that use the same source IP address).This may be applied to EPS bearers configured at the time that the WTRUreceives a configuration that adds the XRB.

Any of the above alternatives may be realized such that a DRB operatesas an XRB when a dormant behavior is activated. When the dormantbehavior is deactivated and the WTRU remains in a connected state, theXRB may revert to its normal DRB operation.

The WTRU may be configured such that, for a given XRB, a subset of userdata (e.g., excluding control plane data) for a given EPS bearer may betransmitted using the configured XRB when a dormant behavior isactivated. Such data may be identified using any of the embodiments forflow classification and routing, which will be explained in detailbelow.

The WTRU may handle user data that is not associated with an XRBaccording to methods applicable when a dormant behavior is notapplicable. For example, for an unsynchronized WTRU with activateddormant behavior, new data that becomes available for transmission thatmay not be transmitted using an XRB may trigger the establishment of anRRC connection (if the WTRU does not have an established RRC connection)and/or scheduling request using random access to request uplinkresources to enable a transmission using a DRB.

The WTRU may not trigger a BSR and/or an SR when new data becomesavailable for the XRB (e.g., based on the parameterlogicalChannelSR-Mask-R1x in the LogicalChannelConfiguration IE). Thismay be applied if a dormant behavior is activated. For example, a WTRUthat uses a dormant behavior may trigger a BSR and/or an SR when newdata becomes available for a DRB or an SRB that is not configured as (orassociated to) an XRB. The WTRU may trigger a BSR and/or an SR for anXRB that is configured such that a BSR and/or SR trigger is allowedaccording to a configuration of the WTRU. As another example, a WTRUthat uses a dormant behavior may trigger a BSR and/or an SR when newdata becomes available for an XRB that is configured such that such BSRand/or SR is not prohibited according to a configuration of the WTRU.

The WTRU may initiate a procedure for transmission of data on uplinkresources in a special subframe when new data becomes available for anXRB. The WTRU may initiate such procedure if a dormant behavior isactivated.

The logical channel configuration (LCH) of the XRB may not be associatedto a logical channel group (LCG), for example, in theLogicalChannelConfiguration IE. The logical channel configuration of theXRB may have a lower priority than that of an SRB. An XRB may have thelowest priority among radio bearers of a WTRU's configuration. This maybe applied if a dormant behavior is activated.

The configuration of the XRB may include an explicit indication, suchthat the WTRU may determine whether or not the concerned XRB may be usedas a DRB for user plane traffic that may benefit from the dormantbehavior (e.g., using a parameter logicalChannelDormant-Mask-R lx in theLogicalChannelConfiguration IE).

The WTRU may configure an XRB for operation without header compressionconfigured. The WTRU may transmit data on an XRB without securityactivated, (e.g., without encryption). This may be a configurable aspectof an XRB. The WTRU may be configured such that an XRB uses the RLCUnacknowledged Mode (RLC UM) operation. The WTRU may be configured suchthat RLC segmentation is not allowed for data transmission whileoperating in a dormant mode (e.g., for data that corresponds to an XRB).The WTRU may disable dormancy behavior for the concerned data transferif the data transmission cannot be accommodated by the transport blockwithout segmentation.

The WTRU may be configured with one or more XRBs. When a plurality ofXRBs are configured, each may be configured to support different levelsof QoS, including parameters, but not limited to, a priority (e.g.,priority in the LogicalChannelConfig IE), an SDU discard timer (e.g.,discardTimer in PDCP-Config IE), a bucket size duration (e.g.,bucketSizeDuration in the LogicalChannelConfig IE), a prioritized bitrate (PBR) (e.g., prioritizedBitRate in the LogicalChannelConfig IE), orthe like.

For the control plane, the WTRU may handle control plane data that isnot associated with an XRB (e.g., data for an SRB) according to anymethods applicable when a dormant behavior is not applicable.

The WTRU may have one XRB for SRB0. SRB0 may be used to (re)establishthe RRC connection and/or to transit to an RRC connected mode. The WTRUmay additionally have one XRB for SRB0, and one XRB for both SRB1 andSRB2. Alternatively, the WTRU may have one XRB for each SRB (i.e., SRB0,SRB1, SRB2). Alternatively, the WTRU may additionally have one XRB forall SRBs. Alternatively, the XRB may be configured by configuring SRBsto transmit user data with control signaling.

Embodiments for flow classification and routing are disclosed hereafter.A WTRU may be configured with an XRB that is associated to an EPSbearer(s) pertaining to a single PGW or it may be configured with an XRBthat is associated to EPS bearers from multiple PGWs. When the WTRU isconfigured with an XRB that is associated with traffic from more thanone EPS bearer, the eNB may perform flow classification and routing ofuser's data towards the proper PGW. Alternatively, when the WTRU isconfigured with an XRB that is associated with traffic from more thanone EPS, the WTRU may perform flow classification and routing of userdata towards the proper PGW. Alternately, a WTRU may be configured withan XRB that is associated to a particular access point name (APN) i.e.,there may be one or more XRBs per APN the WTRU is connected to. In thiscase, the WTRU may perform traffic flow classification and routing ofuser data towards the appropriate APN. If those APNs are accessedthrough the same P-GW, the P-GW may differentiate the traffic for eachAPN and route the packet to the correct network.

A WTRU having a dormant behavior activated may perform flowclassification on traffic generated by different services and/orapplications. The WTRU may be configured with a plurality of packetfilters and/or traffic flow templates (TFTs). The WTRU may be configuredwith first set of packet filters and/or TFTs that may be used when thedormant behavior is not activated, and with a second set that may beused otherwise.

The WTRU may determine, using the configured and applicable packetfilter and/or TFTs, when data may be transmitted using an XRB. Thesepacket filters may be configured in the WTRU by the MME. The MME maysend the packet filters in an activate bearer message, a modify bearermessage, or a new dedicated NAS message towards the WTRU when the EPSbearers are setup. It may be specified in the NAS message that there isa different set of packet filters which may be applied differentlydepending on whether the WTRU is in a connected mode or a dormant mode.Alternatively, the dormant mode packet filters may be sent to the WTRUat the time the WTRU enters the dormancy mode. This is performed by theNAS message which informs the WTRU to enter EMM-Dormant mode.

The WTRU may provide further information related to routing and flowclassification to the eNB. For example, such information may include thenumber of DRBs and/or details related to packet size (e.g., average,maximum, minimum), inter-packet and/or inter-burst delay (e.g., average,maximum, minimum), number of packets in a burst, protocol type (e.g.,transmission control protocol (TCP), user datagram protocol (UDP),real-time transmit protocol (RTP), real-time transmit control protocol(RTCP)). The eNB may use this information to properly configure the WTRUfor the dormant behavior, including XRB configuration. The eNB may usethis information to perform correct mapping of data received for a givenXRB to the S1-U bearers on the link towards the SGW.

Alternatively, the XRB data may be provided to an equivalent S1-U XRBtowards the SGW. A similar functionality may be implemented at the SGWto map the packets to the correct S5 bearer towards the PDN GW. This mayimply the setup (at all time or upon entering of dormant mode or uponsetup of XRB) of an equivalent S1-U XRB between the eNB and the SGW.

Additional means to classify packets may be provided by means ofextension to packet filters, such that at least one of the following maybe received by the WTRU, for example, for the purpose of flowclassification.

Packet filters may include parameters related to the size of a packet,(e.g., maximum size or minimum size). The size may be derived from thelength field of the IP header or the transport header. Alternatively,the size may be derived from the packet data convergence protocol (PDCP)service data unit (SDU) size (uncompressed IP header).

Packet filters may include metrics applicable to the filter including atleast one of a value for inter-packet arrival time for a given rule ofthe filter, parameters to characterize a burst (number of transmissionswithin a given time), a value for inter-packet arrival time for a givenrule of the filter, or a rate at which the rule is being matched bypackets. These value may be used as a threshold and used as additionalrules to validate the filter entry.

The embodiments to trigger dormancy behavior for the WTRU may be appliedat the layer of packet filters and TFTs based on the observation of howthe packets are filtered and/or the observations about classification ofthe packets. When there is such a trigger the WTRU may enter or leavethe dormancy behavior or may send an NAS service request or serviceupdate message, or change the RRC/NAS states. Once the WTRU enters thedormant mode, the WTRU may switch the packet filters and start routingdata towards the XRB or the packet filter may be configured in such away that the WTRU discards some of the background traffic.Alternatively, the WTRU may choose to use the connectionless approach totransmit data (i.e., sending data over the control plane).

Embodiments for session managements for radio access bearers (RABs) witha dormant behavior are disclosed hereafter. When a WTRU has a dormantbehavior activated and the WTRU performs a mobility-related procedure,(e.g., either a WTRU-autonomous procedure such as a cell (re)selectionprocedure that changes the cell on which the WTRU is camping, or aneNB-controlled procedure (e.g., a handover to a different cell, forexample, in case where the WTRU implements a dormant mode behavior as anextension to a connected mode)), the WTRU may perform at least one ofthe following. The WTRU may maintain at least the XRB in the WTRU'scontext, unless the dormant mode is deactivated or unless indicatedotherwise by explicit signaling (e.g., in the RRC connectionreconfiguration message with mobility control IE (i.e., handovercommand)). The WTRU may maintain any DRB(s) associated to the XRB.

For a WTRU-autonomous procedure, the WTRU may initiate a new servicerequest to reestablish the radio access bearers. The WTRU may performthis service request either using RRC signaling (e.g., the target eNBmay reestablish the connection with the concerned MME) or using an NASprocedure. This may be applied if RABs are not maintained and releasedautonomously following a WTRU-autonomous mobility event.

For a WTRU-autonomous procedure, the WTRU may initiate a procedure suchthat the WTRU may indicate to the network its new location. This mayprovide means for the network to setup the WTRU's context to the targeteNB. For example, the WTRU may initiate the tracking area update (TAU)procedure. The TAU procedure may include an indication that resourcesmay be allocated for EPS bearers of the WTRU's context.

For a WTRU-autonomous procedure, the WTRU may deactivate the dormantbehavior including the release of any configured XRB. The WTRU may theninitiate a procedure such that the WTRU may indicate to the network itsnew location. This may provide means for the network to establish an RRCconnection with the WTRU such that a dormant behavior may bereconfigured, if needed. For example, the WTRU may initiate the TAUprocedure. The TAU procedure may include an indication that resourcesshould be allocated for EPS bearers of the WTRU's context.

The above embodiments may apply when a WTRU wants or attempts to exitthe dormant behavior. The exit of dormant mode may be due to a need tosetup resources for additional user plane traffic, traffic that requiresdedicated bearer(s), or the exit may be due to a pending NAS sessionmanagement procedure (activation, modification, or deactivation of atleast one dedicated EPS bearer). The WTRU may exit the dormant mode as aresult of manual closed subscriber group (CSG) selection. If the exit ofthe dormant mode is controlled by the RRC (or lower layers), the NAS mayprovide indications (based on the listed triggers above) to the RRC (orlower layers) which may lead to the exit of the dormant mode by the RRC(or lower layers).

The NAS signaling may be extended to support a dormant mode. A WTRU maydetermine that it needs additional resources for operation in thedormant behavior, either because the WTRU determines that it needs toactivate a dormant mode or because it already uses a dormant behaviorbut needs additional resources for operation in the dormant behavior.The WTRU may be allowed to initiate an NAS service request procedure inthat case. The WTRU may initiate the NAS service request procedure inthe current RRC mode (e.g., CONNECTED, DORMANT, IDLE) and/or EMM state(e.g., EMM-CONNECTED, EMM-DORMANT, EMM-IDLE) that supports a dormantbehavior. The WTRU may be allowed to transmit an NAS service request ina connected mode. This procedure, if accepted by the network, maytrigger the setup of additional resources for dedicated or defaultbearer(s) that are active for the WTRU. Alternatively, the WTRU mayreceive an NAS response in case the network initiate the modification tothe WTRU's currently allocated resources. The response may be a new NASmessage or an existing session or mobility management message (e.g.,with additional IE).

The WTRU may determine that it needs additional resources, for example,because the WTRU determines that it needs to deactivate a dormant mode.The WTRU may be allowed to initiate an NAS service request procedure inthat case. In other words, the WTRU may initiate the NAS service requestprocedure in the RRC mode (e.g., CONNECTED, DORMANT, IDLE) and/or EMMstate (e.g., EMM-CONNECTED, EMM-DORMANT, EMM-IDLE) that supports adormant behavior. Alternatively, the WTRU may receive an NAS servicerequest in case the network initiate the modification to the WTRU'scurrently allocated resources.

The setup of additional resources, due to a WTRU-initiated NAS servicerequest procedure, or due to a network-initiated NAS service requestprocedure (i.e., paging followed by NAS service request from the WTRU),or any dedicated NAS message that triggers an NAS service request (orsimilar NAS procedure) by the WTRU, may result in the WTRU exiting ordeactivating the dormant behavior. Alternatively, the WTRU may beallowed to directly send an NAS session management message (to requestsetup, modify, or deactivate an EPS bearer context) before sending anNAS service request or a similar NAS message such as an NAS serviceupdate. The extended NAS service request may be used to request theactivation or the deactivation of a dormant behavior.

Similar to the extended NAS service request described above, a new NASservice update message may be introduced to modify the WTRU's dedicatedresources, and/or request activation or deactivation of a dormantbehavior. The behavior of the NAS service update may be similar to thatdescribed above for the extended NAS service request.

The WTRU may perform any of the embodiments described above related tomobility management at the NAS layer to request additional user planeresources or to perform NAS session management procedures. Additionallyor alternatively, the WTRU may perform any of the following one orcombination of the embodiments. The WTRU may perform management of radiobearer that may be used while in a dormant mode (e.g., XRB). Forexample, the WTRU may perform setup or reactivation of at least oneradio bearer, or teardown or deactivation of at least one radio bearer.The WTRU may perform management of radio bearers that may be used whenthe WTRU exits a dormant mode (e.g., one or more EPS RABs). The WTRU mayperform set-up or reactivation of at least one radio bearer or teardownor deactivation of at least one radio bearer.

The NAS service request procedure is conventionally used for a WTRU inan idle mode. Extensions to session management may be defined to allowoperation with a dormant behavior. Embodiments are provided herein toallow a WTRU in a dormant mode to request more resources for otherbearers. This implies resource allocation on both the radio and the Siinterfaces, thereby necessitating the MME to be aware of this request sothat both radio and S1resources are set up.

The WTRU may perform at least one of the following procedures while in adormant mode for the management of radio bearers.

In one embodiment, the WTRU may perform WTRU-initiated NAS servicerequest or NAS service update while in a dormant mode. The WTRU mayinitiate an NAS procedure with the MME to modify the user planeresources. For example, the WTRU may send an NAS message (e.g., eitherthe extended NAS service request or a NAS service update) to indicate tothe MME that user plane resources, (e.g., for at least one dedicatedbearer), are needed. The NAS message may include a list of dedicatedbearers for which resources are requested, and may include a time orflag parameter that may be used to indicate the duration of the time forwhich resources are needed. For example, a specific application at theWTRU may require transmission of relatively large amount of data in ashort period of time (e.g., via successive transmissions) such that theresources are not needed after a specific time interval. The setup ofresources for the requested bearer(s) may result in the WTRU exiting adormant mode. Alternatively, the transmission of the NAS message mayresult in the WTRU exiting or deactivating the dormant mode. The WTRUmay subsequently receive an NAS message, confirming the receipt of theWTRU's NAS request, which may inform that the WTRU may exit ordeactivate the dormant mode. The setup of resources for the requestedbearer(s) may result in the WTRU exiting a dormant mode.

The MME may receive the NAS message (e.g., either the extended NASservice request or a NAS service update) from the WTRU. When the MMEreceives the NAS message, the MME may establish the user plane for EPSbearers that are active in the WTRU's context. The MME may be aware thatthe WTRU is in a dormant mode. Alternatively, the received NAS messagemay include an indicator as to which EPS bearers require user planeresources. The MME may take into account a time factor or otherparameter that may be included in the NAS message such that resourcesare set up for a specific period of time. The MME may subsequentlyinform the serving eNB (via S1AP interface, using existing or newmessages) to set up resources for at least one dedicated and/or defaultbearer. The MME may include additional parameters such as time intervalduring which the resources should be maintained in the control signalingtowards the eNB. The MME may run a timer with the indicated value suchthat after its expiry, the MME may inform the eNB to release theresources for one or more dedicated and/or default bearer. The MME maysend a message to the WTRU, confirming the receipt of the NAS message,and may inform the WTRU to exit a dormant mode.

The eNB may receive the S1AP message (new or existing) from the MME toset up resources for the WTRU in a dormant mode. The eNB may thenreconfigure the WTRU to exit a dormant mode. The eNB may start a timer,as per indication in the received message, such that the resources to besetup may be released after expiry of the timer. The eNB may reconfigurethe WTRU to operate in a dormant mode after the expiry of this timer.

In another embodiment, the MME may initiate the NAS request describedabove.

In another embodiment, the NAS may provide information about the type ofrequest to the RRC, (for example, user plane resource setup, NAS sessionmanagement signaling, NAS signaling, etc.). The WTRU RRC may send an RRCmessage to the eNB to request the transition from a dormant mode, forexample, upon a trigger to exit a dormant mode. Alternatively oradditionally, the WTRU RRC may inform the eNB about the pending requestwithout necessarily requesting to exit a dormant mode. It may includeinformation about higher layer (e.g., NAS) requests.

The eNB receives the RRC message from the WTRU in a dormant mode. TheRRC message may include an indication to exit a dormant mode, oralternatively an indication related to NAS protocol. The eNB may thenmake a decision to transition the WTRU from a dormant mode, based onprevious configuration that may have been received, (e.g., from theMME). For example, when the WTRU was initially put in a dormant mode,the MME may have informed the eNB that any future requests to setupresources for additional bearers may be granted without a permissionfrom the MME. Alternatively, the MME may inform the eNB that anytransition from a dormant mode (or into dormant mode) may require apermission from the MME.

The eNB may inform the MME about the pending request. This may be apermission to exit the WTRU from a dormant mode. Alternatively, the eNBmay forward additional information to the MME as received from the WTRU.For example, if the eNB had received a message to setup resources for atleast one dedicated bearer, the eNB may indicate to the MME that theWTRU needs additional resources for at least one dedicated bearer. TheeNB may then wait for the MME to accept or reject the request beforeproceeding. The eNB may include tunnel endpoint identities (TEIDs) thatmay be used by the serving gateway (SGW) for S1-U resource path. The MMEmay forward this information to the SGW if the request is granted.Moreover, the MME may forward TEIDs to the eNB (as received from theSGW) so that user plane path for uplink data may be setup.

The RRC procedure described above may apply if the NAS is not allowed totransmit a service request or other message if the dormant mode is asub-state of the connected mode.

FIG. 5 is a signaling diagram of an example process 500 for sessionmanagement in accordance with embodiment disclosed above. A WTRU NAS(EPS session management (ESM) or EPS mobility management (EMM)) detectsan event to exit a dormant mode (e.g., due to a request from the ESMlayer or from the applications to setup resources), and sends anindication to the WTRU RRC to setup resources or exit a dormant mode(502).

The RRC in the WTRU may then send an RRC message to the eNB with anindication (e.g., a new IE) indicating the desire to exit a dormant modeof operation (504). Alternatively, the WTRU (i.e., NAS) may transmit anNAS message (new or existing) to the network to indicate the desire forexiting a dormant mode.

The eNB sends a new or existing S1AP message to the MME with a new IE toindicate the WTRU's request to exit a dormant mode (506). The S1APmessage may include TEIDs.

The MME after receiving this message may verify the IE and may acceptthe request to exit a dormant mode. Alternatively, if the MME receivesan NAS message from the WTRU, the MME verifies the NAS request and mayaccept the WTRU request to exit a dormant mode. The MME may then triggerthe bearer modification procedure towards the SGW (508). The SGW may inturn trigger the bearer modification procedure towards the PDN GW (notshown), and sends a bearer modification response to the MME (510).

The MME responds to the eNB with a new or existing S1AP message that mayinclude a new IE to indicate the result of the request to exit a dormantmode (512). This message may indicate to the eNB a list of RABS andhence radio bearers that should be setup for the WTRU. Alternatively,the MME may respond with an NAS message towards the WTRU.

The eNB may then send a new or existing RRC message to the WTRU toindicate the result of the request to exit a dormant mode (514). The eNBmay request the WTRU to perform RRC reconfiguration to add other dataradio bearers which implicitly indicates the acceptance to exit adormant mode.

The WTRU RRC may then change its state or other parameters to reflectthe exit of a dormant mode. The RRC may indicate to the NAS that dormantmode operation has been exited which may cause the NAS to change statesor parameters to reflect this change.

Alternatively, if the WTRU receives an NAS message from the MME, theWTRU verifies the result of the request to exit a dormant mode, and ifthe request is accepted, the WTRU NAS may change its state or otherparameters to reflect the exit of the dormant mode. The WTRU NAS mayindicate to the WTRU RRC that dormant mode may be exited. The WTRU NASmay in turn trigger the RRC to change any RRC states. The WTRU may thenuse data radio bearers that are setup for operation in a normal mode(i.e., not a dormant mode) for user plane traffic (516).

Alternatively, the eNB may initiate an RRC request, similarly asdescribed above for the WTRU.

Events occurring in the NAS layer may cause a transition from a dormantmode to a non-dormant mode, and vice-versa.

When a WTRU enters a dormant mode (which may be realized as a subset ofRRC connected mode or a separate RRC state), the NAS may be made awareof this so that the appropriate actions may be taken. For example, in adormant mode, the NAS may send a new message (e.g., service update) torequest resources for dedicated bearers and hence exit a dormant mode.

The RRC and the NAS may interact upon transition to or from a dormantmode at each entity. A change in a dormant mode operation may implytransition from or to a dormant mode of operation at the RRC and/or theNAS.

The RRC may inform the NAS about the change in a dormant mode operation.For example, when the RRC enters a dormant mode of operation, the RRCmay inform the NAS (EMM or ESM) about the transition into a dormantmode. This indication may be valid for a given period of time that iseither known to the NAS or signaled by the RRC. Similarly, the RRC mayinform the NAS about the transition from a dormant mode into a normalmode of operation.

If the NAS is aware of entering or leaving a dormant mode, and if suchtransition may be triggered or controlled by the NAS, the NAS may informthe RRC (or any other layer e.g., ESM or lower layers such as MAC) aboutany transition into or out of the dormant mode.

An entity, such as the NAS, upon receiving an indication abouttransitioning into a dormant mode (e.g., from the RRC or from any otherentity such as the MME), may use or set a parameter that indicates thecurrent mode of operation in the WTRU. For example, upon receipt of anindication that the WTRU is operating in a dormant mode, the NAS maydefine or use a flag or any other parameter that indicates the WTRU'smode of operation. A dormant flag may be defined, (e.g., a Booleanparameter), where TRUE (or 1) may indicate that the WTRU is in a dormantmode, and FALSE (or 0) may indicate that the WTRU is in a normal mode(i.e., not in a dormant mode). This behavior may apply to otherentities/layers in the WTRU (e.g., the RRC, the MAC, or the ESM entityof the NAS).

The indication to the NAS may be from lower layers (e.g., RRC), or maybe from other network entities such as the MME. For example, if the NASreceives an indication about a dormant mode operation or a request toenter a dormant mode from the MME, the NAS may set a flag (or anotherparameter) as described above to know that the WTRU is operating in adormant mode. Similarly, a request to exit a dormant mode or anindication about the exit of a dormant mode that may be received fromthe MME may result in the WTRU changing the value of the dormant flag(or any parameter) such that a normal mode of operation is initiated.

At any time of operation, the NAS may verify whether or not the WTRU isoperating in a dormant mode, either using a flag or a state, or anyother method. The NAS may then behave according to the WTRU's currentmode of operation. The NAS may further verify if this state isconsidered as part of NAS EMM-IDLE or EMM-CONNECTED, or any other state.For example, if the NAS is aware of a dormant mode of operation the NASmay send a service update message for requesting resources for dedicatedbearers. This may be done if the dormant mode is realized as a subset ofEMM-CONNECTED. Alternatively, it may be done regardless of the actualstate that realizes the dormant behavior. Alternatively, the NAS may beallowed to send a service request in a dormant mode. Both the serviceupdate and service request messages may be used. The NAS (EMM or ESM)may prohibit further ESM requests when in a dormant mode. This may bedone for a defined period of time as per indication from lower layers orfrom the network.

At any time of operation, if the NAS identifies that the WTRU is notoperating in a dormant mode, the NAS may avoid using the service updatemessage, except it should be sent to inform the MME that the WTRU NAS isentering a dormant mode.

The NAS may, based on any triggers to enter a dormant mode or based on alower layer request to enter a dormant mode, send a message to the MMEto inform the MME about the WTRU NAS operation in a dormant mode. TheNAS may then enter a new state or keep a flag that indicates operationin a dormant mode. The NAS may enter a new state or keep the flag aftera confirmation or acknowledgement from the MME. The NAS may notify lowerlayers or other entities (e.g., ESM) that the WTRU is operating in adormant mode.

Alternatively, based on an indication received from the WTRU, or basedon a trigger in the MME, the MME may request the eNB to put the WTRU ina dormant mode of operation. This may be done using SlAP messages (e.g.,WTRU CONTEXT MODIFICATION REQUEST) or any new message with an IE definedto indicate that the eNB needs to put the WTRU in a dormant mode. Uponreception of a request from the MME to put the WTRU in a dormant mode,the eNB may then indicate to the WTRU to enter a dormant mode using RRCmessaging. The MME may send an NAS message to indicate to the WTRU thata dormant mode is now active. Alternatively, the NAS in the WTRU may benotified by the RRC or any other layer.

Triggers may be defined to put the WTRU in a dormant mode of operation(where the realization of dormant mode may be either at the NAS, at theRRC, or both). In one embodiment, the session management entity (e.g.,NAS ESM) may observe that the WTRU is transmitting packets that havecertain characteristics (e.g., a specific or maximum packet size, orspecific inter-packet (or burst) arrival time, or any other definedcharacteristic or their combination). The session management entity may,as a result of observing certain traffic pattern, install packet filters(locally and/or via signaling with the MME) such that certain trafficpackets may be grouped into at least one bearer, which may be the XRB.Alternatively, the WTRU may send a new session management message to theMME to inform/request operation in a dormant mode.

The session management entity in the WTRU may wait for anacknowledgement before operating in a dormant mode. The acknowledgementmay be in the form of acknowledging the installment of packet filters inthe uplink and/or downlink, or it may be in the form of a request toinstall a packet filter at the WTRU. The acknowledgement may be in theform of new session management message. The acknowledgement may be sentby the network (e.g., the MME).

The session management entity may receive an indication to enter adormant mode and as a result may perform the predefined actions. Theindication may be local, for example, from applications or from otherentities in the WTRU such as, but not limited to, user plane entities(e.g., the PDCP entity), which may have a functionality to observecertain traffic patterns. The indication may be received from anotherentity in the network, for example, from the session management entityin the network (i.e., the MME).

The session management entity may (e.g., NAS ESM), due to a trigger toenter a dormant mode, indicate to the mobility management entity (e.g.,NAS EMM) that the WTRU now enters a dormant mode. The EMM may performthe predefined actions due to an indication from the ESM to enter adormant mode or due to the same triggers defined above (i.e., theactions defined above may be apply to the EMM).

FIG. 6 is a signaling diagram of an example process 600 of entering adormant mode in accordance with one embodiment. Upon trigger at the WTRU(e.g., ESM or EMM entity of the NAS), the NAS (ESM or EMM) decides tooperate in a dormant mode (602). The trigger may be the detection oftransmission of small packets or any other triggers.

The NAS (ESM or EMM) transmits an NAS message to the network (eNB)(604). The NAS message may be an ESM message, for example, to installpacket filters or an EMM message which may be defined to request adormant mode operation. Alternatively, the NAS may interact with the RRCto indicate the need to enter a dormant mode without necessarilyproviding a NAS message for transmission. In this case, the RRC may sendan RRC message to the eNB with an information element IE that indicatesthat the WTRU wants to enter a dormant mode.

The eNB forwards the received NAS message to the MME (606).Alternatively, if the eNB receives the RRC message with the IEindicating request to enter a dormant mode, the eNB may send an existingor new SlAP message with the new IE (e.g., with a value set to thatreceived from the WTRU) towards the MME. The message may include TEIDs.

The MME may accept or reject the request based on configurations in thenetwork. If the MME accepts the request, the MME may trigger themodification of the bearers towards the SGW (608). The SGW may initiatebearer modification towards the PDN GW (not shown), and send a bearermodification response to the MME (610). The MME may respond to therequest to enter a dormant mode by sending an NAS message (EMM or ESM)to the eNB with the result of the request (612). Alternatively, the MMEmay inform the eNB via existing or new SlAP message about the result ofthe request to enter a dormant mode. The message may include TEIDs.

The eNB forwards any received NAS message to the WTRU (614). The WTRUverifies the NAS (ESM or EMM) message for the result of the request toenter a dormant mode. If the result indicates that a dormant mode isaccepted, the NAS may enter a dormant mode. The NAS may additionallyindicate to the RRC that the WTRU needs to operate in a dormant mode.The RRC may enter a dormant state. The WTRU may install packet filtersif requested by the NAS message.

Alternatively, the eNB may send an RRC message with an IE indicating theresult of the dormant mode request. The RRC verifies the message and mayinform the NAS about the response. The NAS and/or the RRC may then entera dormant state and/or set a certain flag accordingly to reflect thedormant mode behavior if the results indicates so. User plane data maybe transferred between the WTRU and the SGW in a dormant mode (616).

Embodiments for per-flow access barring in a dormant mode are disclosedhereafter. The increase in an intermittent background traffic from alarge population of inactive WTRUs may significantly contribute togeneration of excessive load in the system, in particular during peaktimes where other WTRUs may be active with services and/or data ofhigher priority. Such load may include user plane traffic, accessattempts on an RACH, and control plane signaling, etc. The RACH overloadmay pre-empt higher priority data to be served. Control plane signalingrelated to radio resource management (RRM) of background services maypre-empt useful user plane traffic for high priority services.

For WTRUs with an established RRC connection and/or with configureddedicated resources, the network may use a combination of QoSconfiguration parameters (per radio bearer) and scheduling priorities(between RABs of a given WTRU and/or between different WTRUs) to ensurethat QoS requirements for different services are met in a cell.Alternatively, the network may update the packet filters such that oneor more flows are discarded by the WTRU, which requires involvement fromthe MME (NAS) to address a problem (congestion) experienced by the eNB.

For WTRUs with an established RRC connection and/or with configureddedicated resources, the network may redistribute WTRUs to other cells(using a handover) or release the WTRU RRC connection (using the RRCconnection release procedure possibly with redirection to another cell)in case of overload in the system (e.g., few or no resources availableto serve higher priority data or WTRUs).

For WTRUs in an idle mode, the network may either signal in the systeminformation parameters that affect the behavior of WTRU's cell(re)selection procedure (such that the cell has a lower likelihood ofbeing selected), or use mechanisms such as extended cell barring bywhich particular type of services may be temporarily pre-empted accessto the cell while others are allowed (e.g., emergency calls) Extendedcell barring relies on broadcast of system information and is applicablein the IDLE mode, and the classes are defined per WTRU.

Embodiments for delaying or pre-empting one or more WTRUs to access thesystem for a given period of time in combination with the use of adormant behavior are disclosed hereafter. The embodiments may allow thenetwork to perform some form of back-off for data associated to certaintypes of services and/or to perform graceful degradation of suchservices provided to one or more WTRUs, (e.g., for WTRUs that are usinga dormant behavior and/or for WTRUs configured with at least one XRB).

In the embodiments, back-off may be applied for certain types ofservices in combination with packet filters and/or radio bearerconfiguration. The embodiments may be applied in the RRC CONNECTED orRRC IDLE mode (e.g., with dormancy behavior such as packet filters andRAB configuration that may remain in the WTRU's configuration), or inthe RRC DORMANT mode.

The embodiments may be useful when the system reaches an excessive load,by which data with higher priority may no longer be served in the celland/or admission control may no longer accept further connections. Suchconditions may be due to the system reaching the maximum number ofpossible RRC connections, due to insufficient system capacity, due tocongestion of the control channels, and/or due to congestion on therandom access channels.

When back-off is applied, a WTRU may not access the system and/orperform a request for uplink resources (e.g., scheduling request usingeither dedicated resource or random access, or a preamble transmissionin the WTRU-specific PRACH occasion) for the user data to which theback-off function is applicable. Alternatively, the WTRU may delay anyrequest related to the user data for which the back-off function isapplicable until a certain amount of data (that may be configurable) isavailable for transmission in the WTRU's buffer. Alternatively, the WTRUmay refrain from sending any request related to the user data for whichthe back-off function is applicable for data in excess of theprioritized bit rate, or for DRBs of the WTRU's configuration.

The WTRU may be configured to determine one or more flows to apply theback-off function (hereafter referred to as “applicable flows”), forexample, based on at least one of XRB, packet filters, service typeand/or QoS parameters, or the like, (which may be given as part of a DRBconfiguration).

The WTRU may be configured to determine when to apply the back-offfunction to the applicable flows, for example, based on at least one ofa WTRU dormant behavior, a WTRU state (e.g., a RRC DORMANT state), animplicit indication, an explicit indication from the network (e.g., anoverload indication broadcasted as part of system information and/or aindication of the allowed service class in the cell), a specificsubframe (e.g., a scheduling occasion), or the like.

The WTRU may be configured to determine how long to apply the back-offfunction for the applicable flows. The WTRU may apply the back-offfunction for a specific (configurable) amount of time. The WTRU mayapply the back-off function until the back-off function is no longerapplicable, e.g., when it no longer meets pre-defined conditions, whenthe WTRU changes an RRC state, and/or when the dormant behavior is nolonger applicable. In addition, the WTRU may stop applying the back-offfunction when a mobility event occurs (change of serving cell) eitherfrom a cell (re)selection procedure that result in a different servingcell or from the reception of a RRC connection reconfiguration with amobility control IE (e.g., handover).

If the WTRU performs any uplink transmission that includes a BSR while aback-off function is applied to some of its radio bearers, the WTRU mayreport a non-zero amount of data for those radio bearers in a BSR, ifapplicable.

A traffic class may represent a relative priority among differentservice classes, (e.g., highest priority, high priority, mediumpriority, low priority, lowest priority). The priority may be accordingto an assigned integer, for example, [15, . . . , 0] where 15 mayrepresent the highest priority. The traffic class may be a priorityassociated to a logical channel group (LCG) associated to the radiobearer's configuration, if applicable.

In a dormant mode, the WTRU may pre-empt requests for DRBs assigned witha low traffic class. For example, the WTRU may be configured with aplurality of DRBs and one or more DRBs may be associated with an XRB.The XRB may be associated with a traffic class. Alternatively, a DRB maybe associated with a traffic class. When operating in a dormant mode,the WTRU may apply a back-off function for data corresponding to atraffic class below a configured value, (e.g., the WTRU may not initiatea request for uplink resources to the network). This may be applied whena period for which the WTRU determines that the serving cell is in anoverloaded condition, for example, from reception of system broadcastinginformation. If the WTRU performs an uplink transmission for a radiobearer of a higher traffic class, which transmission may include a BSR,the WTRU may report in a BSR the amount of data for the DRBscorresponding to the lower traffic class.

In another embodiment, in a dormant mode, the WTRU may pre-empt requestsfor data in excess of the DRBs PRB. For example, the WTRU may beconfigured with a plurality of DRBs and a DRB may be associated with atraffic class. In a dormant behavior, the WTRU may apply a back-offfunction for data corresponding to a traffic class below a configuredvalue such that the WTRU may not initiate a request for uplink resourcesto the network for data for the applicable DRBs in excess of the PRB.This may be applied when the serving cell is in a condition of overload,that may be determined based on reception of system broadcastinginformation.

A WTRU may be configured with a plurality of packet filters. Each packetfilter may be associated with an index, (e.g. starting from 0 and up).The WTRU may have one packet filter active at any time. The WTRU mayconsider the packet filter with the lowest index as a default packetfilter. The WTRU may change the active packet filter based on anindication received from the network. This indication may be received inthe system information broadcast. The system information broadcast maysignal an index applicable to the WTRUs configured with a plurality ofpacket filters in the cell. A WTRU may use a packet filter differentthan the default packet filter if it operates in a dormant mode. If aWTRU is configured with a number of packet filters and the highestconfigured index is smaller than the value indicated by the systembroadcasting, the WTRU may use the index with the highest value.

The TDF-based control plane policing may consider the following cases:network-based and WTRU-based. In the network-based TDF-based controlplane policing, the unwanted user plane traffic patterns are identifiedat the network (e.g., the PGW) and then the network correlates thesepatterns with potential control plane events that may cause unwantedsystem behavior. The network may then take actions to mitigate relevantcontrol plane congestion. In the WTRU-based TDF-based control planepolicing, the WTRU detects the unwanted user plane traffic pattern andeither notifies this behavior to the network for the network to take anaction to correlate control plane events and mitigate possible unwantedsystem behavior, or enforces ADC-rules by correlating user plane trafficpatterns with control plane events and mitigate potentiallyharmful/undesirable control plane events.

FIG. 7 shows an example procedure for TDF-based control plane policingin accordance with one embodiment. FIG. 7 shows both network-based andWTRU-based TDF-based control plane policing.

Based on rules set by the PCRF or preconfigured by an operator, the PGWmay detect a traffic pattern. Upon detection of the traffic pattern, thePGW reports this event to the PCRF (702). The PCRF receives the trafficdetection information and configures application detection and control(ADC) rules in the PGW (704). The PGW uses these rules to identifypotential user plane traffic that may be later correlated with controlplane events (706). For example, the TDF in the PGW uses the providedrules to identify the application within the service data flows by usingan application ID provided by the PCRF as part of the ADC rules.

If the PGW identifies a specific pattern according to the rules, the PGWmay notify control plane management entities about the user planeunwanted behavior that may be correlated at the control plane managemententity to determine corrective actions. The corrective actions include,but are not limited to, preventing certain control plane events such assending a new service request or a new RRC connection request for thepurpose of establishing a new connection. The PGW passes thisnotification to the MME, for example, by sending an update bearerrequest through the SGW (708, 710).

The MME correlates the traffic detection information with the knownsignaling patterns. The MME may then send an E-RAB MODIFY REQUEST or DLNAS TRANSPORT message to either setup a new dormant bearer to preventthe establishment and tearing down of short-lived connection for thepurpose of sending a few bytes, setup a new filter to direct packets toan existing dormant bearer, or to communicate/notify the traffic patternidentification to the eNB for the eNB to take further actions dependingresource availability (712).

Alternatively, the MME send an E-RAB MODIFY REQUEST or DL NAS TRANSPORTmessage or similar message to initialize a back-off timer in the WTRU toprevent any new control plane message for the duration of the back-offtimer (712). The eNB may then forward this timer to the WTRU via RRCsignaling (714). Alternatively, the MME may send the timer to the WTRUdirectly via NAS signaling.

The back-off timer may be applied to specific control plane messages,such as a service request (i.e., when provided with this timer, the WTRUmay not send a service request (for any service) for the duration of thetimer). Alternatively, the WTRU may be allowed to send a service requestfor voice calls, emergency calls, or other services. What services areallowed and what services are not allowed may be provided to the WTRU.

Alternatively, the back-off timer may be applied to specific trafficclasses, or specific bearers or flows. For example, when the WTRU isprovided with a back-off timer, the WTRU may not transition to aconnected mode for traffic generated on a specific bearer or for aspecific flow. Alternatively, the back-off timer may be applied to theentire WTRU.

For the WTRU-based TDF-based control plane policing, the WTRU isconfigured with the ADC rules or the filtering information may beprovided to the WTRU, for example, during a bearer establishment. TheWTRU uses these rules to detect traffic patterns. Once the trafficpattern is detected, the WTRU may send notification towards the PCRF (orany other node, such as the MME) using, for example, a bearer resourcerequest or a generic transport of NAS messages (or any session ormobility management NAS message) (702 a). The WTRU may provide thisindication to the MME, which may then forward it to the PCRF via the SGWand the PGW using the CN messages, such as a modify bearer requestmessage. Alternatively, a new message may be defined between thesenodes. Once this message (i.e., triggers from the WTRU) is received bythe PCRF, the PCRF may take the actions as in the operations 702-714 inFIG. 7.

Alternatively, the WTRU may use the configured ADC rules to enforce someof the actions. The WTRU may trigger the request of a dormant bearer asdisclosed above. Alternatively, the WTRU may route packets from theunwanted flow to a dormant bearer. FIG. 8 shows routing of the packetsfrom the unwanted flow to an XRB. The user plane filter 802 in the WTRU,which may be controlled in accordance with the TDF/ADC 806 configured bythe PGW, routes the matched traffic to the XRB 804.

Alternatively, the WTRU may back-off for the duration of a preconfiguredtime, refraining from sending specific control plane messages for aspecific flow or bearer, or sending any control plane messages for theduration of the preconfigured timer.

Paging may be used to transmit paging information to a WTRU in RRC_IDLEand/or to indicate to a WTRU in RRC_DORMANT the availability of downlinkdata for the WTRU. Paging may be used to inform WTRUs in RRC_IDLE,RRC_DORMANT, and RRC_CONNECTED about a system information change, toinform about an ETWS primary notification and/or ETWS secondarynotification, and/or to inform about a CMAS notification.

The paging information is provided to upper layers, which in responsemay initiate RRC connection establishment, e.g., to receive an incomingcall. The upper layers may in response resume decoding of downlinkcontrol signaling at the physical layer (e.g., to receive a shortunicast data transfer).

The network may initiate the paging procedure by transmitting the pagingmessage at the WTRU's paging occasion. The network may address multipleWTRUs within a paging message by including one paging record for eachWTRU. The network may indicate a change of system information, and/orprovide an ETWS notification or a CMAS notification in the pagingmessage.

Upon receiving the paging message, if in RRC_IDLE, for each of thepaging record, if any, included in the paging message, if theWTRU-Identity included in the paging record matches one of the WTRUidentities allocated by upper layers, the WTRU may forward theWTRU-Identity and the en-Domain to the upper layers.

Upon receiving the paging message, if in RRC_DORMANT, for each of thepaging record, if any, included in the paging message, if theWTRU-Identity included in the paging record matches one of the WTRUidentities allocated by upper layers, the WTRU may indicate to the lowerlayers that monitoring of downlink control signalling may be resumed.

If the systemInfoModification is included, the WTRU may re-acquire thesystem information using the system information acquisition procedure.If the etws-Indication is included and the WTRU is ETWS capable, theWTRU may re-acquire SystemInformationBlockType1 immediately, i.e.,without waiting until the next system information modification periodboundary. If the schedulinglnfoList indicates thatSystemInformationBlockType10 is present, the WTRU may acquireSystemInformationBlockType10. If the schedulinglnfoList indicates thatSystemInformationBlockType11 is present, the WTRU may acquireSystemInformationBlockType11. If the cmas-Indication is included and theWTRU is CMAS capable, the WTRU may re-acquireSystemInformationBlockType1 immediately, i.e., without waiting until thenext system information modification period boundary. If theschedulinglnfoList indicates that SystemInformationBlockType12 ispresent, the WTRU may acquire SystemInformationBlockType12.

Although features and elements are described above in particularcombinations, one of ordinary skill in the art will appreciate that eachfeature or element can be used alone or in any combination with theother features and elements. In addition, the methods described hereinmay be implemented in a computer program, software, or firmwareincorporated in a computer-readable medium for execution by a computeror processor. Examples of computer-readable media include electronicsignals (transmitted over wired or wireless connections) andcomputer-readable storage media. Examples of computer-readable storagemedia include, but are not limited to, a read only memory (ROM), arandom access memory (RAM), a register, cache memory, semiconductormemory devices, magnetic media such as internal hard disks and removabledisks, magneto-optical media, and optical media such as CD-ROM disks,and digital versatile disks (DVDs). A processor in association withsoftware may be used to implement a radio frequency transceiver for usein a WTRU, UE, terminal, base station, RNC, or any host computer.

1. A method of a wireless transmit receive unit (WTRU), the methodcomprising: receiving a radio resource control (RRC) configuration in aCONNECTED state utilizing an associated connectivity context of theWTRU; transitioning in a first move to a DORMANT state from theCONNECTED state based on the RRC configuration; transitioning in asecond move back to the CONNECTED state from the DORMANT state, whereinthe second move further includes utilizing the associated connectivitycontext.
 2. The method of claim 1, wherein the second move is triggeredby receiving a paging message.
 3. The method of claim 1, wherein thesecond move is triggered by sending a request to reconnect.
 4. Themethod of claim 1, wherein the connectivity context information includessecurity information.
 5. The method of claim 1, wherein the RRCconfiguration is based on a C-RNTI.
 6. The method of claim 1, whereinthe DORMANT state has a specific DRX configuration.
 7. The method ofclaim 1, further comprising performing cell re-selection while in theDORMANT state.
 8. A wireless transmit receive unit (WTRU), the WTRUcomprising: a processor, a transceiver operatively coupled to theprocessor, the transceiver and processor configured to receive a radioresource control (RRC) configuration in a CONNECTED state utilizing anassociated connectivity context of the WTRU; the transceiver andprocessor further configured to transition in a first move to a DORMANTstate from the CONNECTED state based on the RRC configuration; and thetransceiver and processor further configured to transition in a secondmove back to the CONNECTED state from the DORMANT state, wherein thesecond move further includes utilizing the associated connectivitycontext.
 9. The WTRU of claim 8, wherein the second move is triggered byreceiving a paging message.
 10. The WTRU of claim 8, wherein the secondmove is triggered by sending a request to reconnect.
 11. The WTRU ofclaim 8, wherein the connectivity context information includes securityinformation.
 12. The WTRU of claim 8, wherein the RRC configuration isbased on a C-RNTI.
 13. The WTRU of claim 8, wherein the DORMANT statehas a specific DRX configuration.
 14. The WTRU of claim 8, wherein thetransceiver and processor are further configured to performing cellre-selection while in the DORMANT state.